codeart.ru

Мой вариант функции get_host_from_url, написанной на erlang

Evgeny Sergeev — Thu, 17 May 2012 15:47:45 +0000

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

Итак, начнем с формализации поставленной задачи.

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

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

Теперь о том, что мы будем делать. Вот небольшая спецификация того, как должна работать функция:

get_host_from_url("http://www.codeart.ru") // ["www.codeart.ru"]

get_host_from_url("http://www.codeart.ru/some/tail/here") // ["www.codeart.ru"]

get_host_from_url("www.codeart.ru") // ["www.codeart.ru"]

get_host_from_url("www.codeart.ru/some/tail/here") // ["www.codeart.ru"]

get_host_from_url("/some/tail/here") // empty (примечание: empty - это атом, а не строка)

get_host_from_url("http://") // empty

get_host_from_url("") // empty

get_host_from_url(undefined) // empty

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

Переходим к самой функции. Начнем обработку с простейшего варианта - когда вместо урла передается значение undefined:

get_host_from_url(undefined) ->

  empty;

Теперь добавим обработку урлов, которые начинаются с префикса “http://”:

get_host_from_url(Url) ->

         case re:run(Url,"http:\/\/([^/]*)", [{capture,[1], list}]) of

                {match, [[]]} ->

                        empty;

                {match, Host} ->

                        Host;

                nomatch ->

                        empty

        end.

Нетрудно заметить, что регулярное выражение, которое используется в функции выше, не охватывает случаи, когда в урле отсутствует префикс “http://”. Я не особый любитель сложных регулярных выражений, поэтому не буду даже пытаться искать вариант при котором в рамках одной регулярки можно обрабатывать два варианта строк - с “http://” и без. Вместо этого я хочу сделать дополнительную функцию.

И вот здесь я не знаю как поступить наилучшим образом. Мне в голову пришло такое решение - я создал дополнительную функцию следующего вида:

get_host_from_url(without_http, Url) ->

        case re:run(Url, "([^/]*)", [{capture, [1], list}]) of

                {match, [[]]} ->

                        empty;

                {match, Host} ->

                        Host;

                nomatch ->

                        empty

                end

Данная функция должна обрабатывать урлы, у которых нет префикса “http://”. Нетрудно заметить, что данная функция не обрабатывает “чистые” урлы - у которых имя хоста совпадает с именем урла. Но если урл чистый, то для него никаких проверок не требуется, поэтому я сделал следующую функцию:

get_host_from_url(without_tail, Url) ->

                Url.

В итоге у меня получился следующий код:

get_host_from_url(undefined) ->

        empty;

get_host_from_url(Url) ->
case re:run(Url,"http:\/\/([^/]*)", [{capture,[1], list}]) of
{match, [[]]} ->

                        empty;
{match, Host} ->

                        Host;

                nomatch ->

                        get_host_from_url(without_http, Url);

                _ ->

                        empty

        end.
get_host_from_url(without_http, Url) ->

        case re:run(Url, "([^/]*)", [{capture, [1], list}]) of

                {match, [[]]} ->

                        empty;

                {match, Host} ->

                        Host;

                nomatch ->

                        get_host_from_url(without_tail, Url)

                end;

get_host_from_url(without_tail, Url) ->

                Url.

Хочу обратить внимание, что когда я описывал функции по отдельности в секции “nomatch” я указывал значение “empty”, а в итоговом варианте я сделал вызов соответствующих функций.

Лично мне полученный код очень нравится. Достаточно прозрачный и чистый. Возможно несколько многословный, но красивый :-). Очень интересно услышать ваше мнение, и, конечно же, любая критика приветствуется.

P.S. я вижу, что в коде есть дублирование и от него, естественно, надо избавиться. Я пока вижу вариант с вынесением обработки регулярного выражения в отдельную функцию, которая выглядит как-то так:

get_host_from_url(by_regexp, RegExp, Url) ->

        case re:run(Url, RegExp, [{capture, [1], list}]) of

                {match, [[]]} ->

                        empty;

                {match, Host} ->

                        Host;

                nomatch ->

                        empty

                end.

Конкурс на создание первого дефейса провалился

Evgeny Sergeev — Wed, 16 May 2012 14:42:54 +0000

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

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

Что-ж, отрицательный опыт - это тоже опыт. В следующий раз я подойду более основательно к организации конкурса. Сейчас активно работаю над переводом defaceit.ru на erlang и ChicagoBoss. После перевода обязательно запущу еще один конкурс, и там учту все свои ошибки.

Оказалось, что chef-solo для меня удобнее чем chef-server

Evgeny Sergeev — Wed, 16 May 2012 03:33:07 +0000

Напомню, что не так давно начал разбираться с утилитами управления конфигурацией сервера, в частности с Chef. Я попробовал как централизованный вариант, когда конфигурация располагается на сервере. Так и локальный вариант, когда все необходимые “рецепты” располагаются непосредственно по месту установки. В итоге пришел к выводу, что второй вариант предпочтительнее и далее несколько слов почему.

Есть такое слово “простота”

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

Безусловно, все эти мелочи далеко не бесполезны, каждая из них позволяет сократить затраты на сопровождение инфраструктуры в будущем. НО! Все это имеет смысл только в случае если количество серверов, которыми нужно управлять, исчисляется если не сотнями, то десятками точно. В противном случае управлять конфигурацией становится мучительно больно. Нет, правда! Когда у тебя всего десяток серверов, которые похожи друг на друга как братья близнецы, то совсем не хочется создавать все эти роли, раздавать права и т.д.

Короче, я так и не смог для себя найти комфортного варианта работы с chef-server. Например, я так и не понял как должен осуществляться деплой конфигурации в промышленных масштабах. Для того чтобы конфигурация применилась на сервере нужно запустить команду “chef-client”. Единственный вариант, при котором не нужно заходить на сервер для запуска этой команды, - это запуск chef-client по расписанию. Но тогда не понятно как быть с повторным применением рецептов. Да и вообще, как-то некрасиво все это

Есть такое слово “контроль”

Зато гораздо интереснее мне показалось использование chef-solo. Здесь для развертывания конфигурации нужно “доставить” рецепты на целевой сервер и запустить команду chef-solo, скормив ей при этом необходимую конфигурацию. Несмотря на то, что в данном случае так же нужно запускать команду на сервере данная схема мне показалась более прозрачной. Хотя бы потому что я сам могу решать каким механизмом доставить необходимые рецепты на сервер. Так же я сам могу подготовить наборы рецептов, которые будут представлять из себя своеобразные пакеты установки. Я могу иметь несколько таких пакетов, для развертывания системы. Так же я могу иметь пакеты для обновления уже установленного программного обеспечения и т.д. Каждый пакет - это просто архив, который закидывается и исполняется на сервере.

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

Сам пакет готовится на моей локальной машине и закидывается на сервер через ssh, здесь так же можно написать небольшой скрипт, который будет раскладывать пакеты на нужное количество серверов. В итоге получается более прозрачная и контролируемая схема, чем вариант с использованием chef-server.

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

Есть такое слово “расширяемость”

Еще одна идея с chef-solo связана с “синхронизацией” локальной виртуалки для разработки и боевого сервера. Здесь так же можно автоматизировать за счет применения скриптов. Скажем, сначала пакет закидывается на виртуалку. Происходит его инсталляция, прогон всех тестов и в случае успеха последних деплой пакета на боевой сервер. В итоге имеем соответствие на боевом и тестовом сервере, которая работает в полуавтоматическом режиме. Что совсем даже неплохо.

Проблемы с Vi и клавишами управления курсором (стрелки) в Ubuntu

Evgeny Sergeev — Sat, 12 May 2012 15:00:24 +0000

Наткнулся на странные грабли - в режиме редактирования в Vi не работают клавиши управления курсором. Вместо ожидаемого перемещения в указанном направлении вставляется латинская буква и перенос строки, буква меняется в зависимости от нажатой клавиши. Я нашел как можно восстановить нормальное поведение, но так и не понял в чем корень проблемы. Может кто-нибудь пояснить в чем дело?

Решение следующее: в ~/.exrc добавить строку “set nocp”. Вроде как данная команда отменяет “строгую совместимость”. Но, блин, что такое “строгая совместимость”? В чем корень проблемы? В общем, мне совершенно это неясно. Надеюсь на вашу помощь!

Проблемы при установке php-fpm через chef server

Evgeny Sergeev — Wed, 09 May 2012 15:54:43 +0000

Продолжаю знакомство с разными утилитами, которые должны облегчить мне жизнь. Вчера разбирался с Vagrant, сегодня начал разбираться с Chef. Chef - это утилита для управления конфигурацией сервера. Обычно применяется для однотипной настройки большого количества серверов, например может применяться в облачных средах. Далее немного о Chef и проблемах в установке php-fpm.

Самое большое преимущество Chef в том, что можно один раз написать интеграционные скрипты и затем тупо запусткать их на всех своих серверах. Сегодня я покопался как с chef solo, так и с chef server. Первый используется для деплоя конфигурации непосредственно на сервере, а второй позволяет организовать централизованное управление конфигурациями всех ваших серверов.

Правда во втором случае приходится завести Chef Account на сервере разработчика. Серверное решение можно использовать бесплатно в случае если обслуживается менее пяти узлов, в остальных случаях придется платить деньги. Причем, самый дешевый вариант стоит 120$ и позволяет управляет конфигурацией 20 узлов.

Я пока использую бесплатный план, в ознакомительных целях, но потом планирую перейти на что-то более существенное, так как 5 узлов - это совсем никуда не годится.

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

Для того чтобы устанавливать софт на сервер у Chef есть готовые скрипты, которые называются рецепты. В этих скриптах подробно описано какие шаги должны быть выполнены при установке той или иной программы. В моем случае я захотел установить php-fpm, данный рецепт имеет зависимость от рецепта dotdep, поэтому пришлось стянуть оба рецепта.

В процессе отработки этих рецептов у меня возникла ошибка и после чего процесс установки завершился. Опытным путем было установлена, что проблема возникает в процессе работы команды:

sudo apt-get install php5-fpm

При этом apt-get валится со следующей ошибкой:

The following packages have unmet dependencies:

  php5-fpm: Depends: libssl0.9.8 (>= 0.9.8m-1) but 0.9.8k-7ubuntu8.5 is to be installed

                 PreDepends: dpkg (>= 1.15.7.2) but 1.15.5.6ubuntu4.1 is to be installed

Не буду ходить вокруг да около, а сразу скажу, что после долгого разбирательства было установлено, что рецепт dotdep добавляет свой apt репозиторий. При попытке установить php-fpm из данного репозитория возникает конфликт зависимостей между установленными и новыми пакетами. Я так и не смог понять каким образом можно поправить данную проблему, не трогая сами рецепты. Поэтому я просто переписал рецепт dotdeb. В результате у меня получился следующий скрипт:

execute "apt-get update".
execute "sudo apt-get install -y python-software-properties".
execute "sudo add-apt-repository ppa:brianmercer/php5" do

    action :run

    notifies :run, resources(:execute => "apt-get update"), :immediately

end

Который я успешно запихал в dotdeb/recipes/default.rb. После данного вмешательства установка php-fpm прошла на ура.

Завтра буду пробовать ставить nginx, хочу чтобы он собирался из исходников. Сегодня мельком глянул готовый рецепт, вроде есть там такая возможность. В общем, завтра посмотрю что к чему. За сим откланиваюсь.

Как установить Vagrant на Ubuntu 12.04

Evgeny Sergeev — Tue, 08 May 2012 03:35:30 +0000

По наводке одного моего хорошего друга и коллеги - Димы Пяткова aka Dkrnl начал разбираться с Vagrant. Думаю, здесь будет уместно пояснить, что Vagran - это утилита, работающая из командной строки и позволяющая управлять виртуальными машинами на базе VirtualBox. Хотя сами разработчики позиционируют этот продукт несколько иначе, но на самом деле все обстоит именно так как я описал.

В принципе, я давно уже использую VirtualBox в процессе разработки своих проектов. Это действительно удобно. Но до сих пор у меня не было удобного механизма управления моими виртуальными машинами, поэтому Vagrant пришелся весьма кстати. Я думаю, что вам эта утилита так же окажется полезной, поэтому хочу рассказать о том, как установить Vagrant на Ubuntu 12.04 LTS.

Установка Ruby и RubyGems

Vagrant разработан на языке Ruby, поэтому без поддержки этого языка на вашей рабочей станции не обойтись:

$ sudo apt-get install ruby1.8 ruby1.8-dev rubygems1.8

$ sudo ln -s /usr/bin/ruby1.8 /usr/bin/ruby

На всякий случай проверяем,что все установилось корректно:

$ ruby -v

ruby 1.8.7 (2011-06-30 patchlevel 352) [x86_64-linux]

Установка VirtualBox

Здесь все просто, идем на официальный сайт, качаем дистрибутив и следуем инструкциям по установке. Останавливаться на этом я не буду.

Устанавливаем Vagrant

Можно скачать vagrant в deb пакете, но я предпочел установить его через утилиту gem:

$ sudo gem install vagrant

Создаем первую виртуальную машину

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

Я предпочитаю использовать в своих проектах Ubuntu 10.04 Lucid32. В принципе, никто не мешает подобрать другой образ, который наилучшим образом будет удовлетворять вашим потребностям и хотелкам.

Стоит отметить, что для связи с гостевой системой используется механизм Shared Folders, о котором я уже неоднократно писал. Идея в том, что папка из которой вы запускаете гостевую систему автоматически пробрасывается в виртуальную машину. Таким образом нет необходимости для каждого образа настраивать Shared Folders, что очень удобно!

Но давайте вернемся к тому как запустить первую виртуальную машину, созданную с помощью Vagrant:

$ vagrant box add lucid32 http://files.vagrantup.com/lucid32.box

$ vagrant init lucid32

$ vagrant up

Пожалуй, нужно пояснить, что команда vagrant box add нужна для того, чтобы скачать базовый образ гостевой системы, у вас может быть несколько образов разных систем, но для большинства разработчиков базовый образ будет один. Образ нужно скачать только один раз - при создании первой гостевой системы, потом он будет браться из локального хранилища.

Команда vagrant init нужна для того чтобы создать конфигурационный файл Vagrantfile, в котором нужно будет описать все конфигурационные опции вашего проекта. Об этом файле более подробно я напишу позже. Отмечу, что данная команда выполняется единожды - при создании нового проекта Vagrant.

Ну и команда vagrant up нужна для запуска виртуальной системы.

Используем SSH для подключения к гостевой системе

Для подключения к гостевой системе используется протокол ssh, и делается это довольно просто:

$ vagrant ssh

На этом установка Vagrant завершена. После этого вы можете заняться настройкой ваше гостевой системы. Это можно делать разными способами, я, например, решил использовать для этого утилиту Chef Solo, которая хорошо интегрируется с Vagrant.

Итоги акции “Провокация” за апрель

Evgeny Sergeev — Mon, 07 May 2012 03:46:54 +0000

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

1. Блог страницы свободного человека
2. Интернет маркетинг от очаровательной блондинки
3. Блог Тормоза
4. Блог Лобач.info (уже второй раз в это рейтинге)
5. Блог Антона Шевчука

Кроме рейтинга еще пару новостей, которые не хочется пихать в отдельный блог.

Во-первых, я таки переполз с Fedora Linux и KDE на Ubuntu и Unity. Пока очень даже нравится. Приятно, что все девайся заработали прямо из коробки, даже usb-микрофон, с которым в Федоре пришлось покопаться.

Во-вторых, не могу не похвастаться тем, что приобрел себе новый фотик - Sony Alpha 77, c китовым объективом 16-50 SSM/2.8. Аппарат очень нравится, первую неделю вообще не выпускал его из рук. Фотал все подряд.

Впечателения от Amazon Simple Queue Service (SQS)

Evgeny Sergeev — Fri, 27 Apr 2012 12:13:16 +0000

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

Если сказать коротко, то обмен сообщениями через общую очередь сообщений мне бы пригодились для проектов SnappySnoop и Defaceit. Думаю, что мало кто помнит о моем проекте SnappySnoop, поэтому позволю себе немного рассказать о том что это за проект такой.

SnappySnoop - это сервис мнений и комментариев. Основная идея состоит в том, что каждый может оставить свой комментарий на любом сайте, даже если сам сайт не имеет механизмов для размещения комментариев. Реализация состоит в том, чтобы подгрузить на сайт JavaScript, который загрузит комментарии и отобразит их на сайте. Фактически все комментарии храняться на сайте SnappySnoop, а отбор нужных комментариев обеспечивается на основе полного урла страницы, на которой запущен скрипт. Не трудно понять, что серверная часть данной задачи представляет из себя самую обычную очередь.

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

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

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

Что здесь хочется отметить. Практически для всех популярных языков (включая Erlang) существуют библиотеки, которые позволяют работать с Amazon SQS.

Для работы необходимо иметь Public и Private Secure Keys, а так же знать ункальный URL для доступа к очереди. Фактически чтение и запись в очередь может быть выполена из любой точки сети Интерент. Но внешний трафик стоит денег, в отличии от сайтов, размещенных в облаке. Последним досутп к очереди будет бесплатным (при условии что они находятся в одном датацентре с очередью сообщений).

Сами данные могут размещаться как с помощью Get, так и с помощью Post запросов. Ответ будет оформлен в виде XML документа, в котором будет содержаться информация о результатах выполнения заданной операции.

В принципе можно работать с содержимым очереди с помощью JavaScript. Но здесь есть одна проблема - ограничения безопасности самого браузера. Если очередь размещена в рамках того же домена, что и сайт на котором запущен JavaScript, то нет никаких проблем с использованием XMLHttpRequest. Мы просто отправляем Ajax запросы и получаем необходимые ответы.

Все портится когда мы выходим за рамки одного и того же домена. Здесь пока остается только один вариант взаимодейтсвия - JSONP. Т.е. ответ сервера должен быть оформлен в JSON формате, да еще быть обернутым с помощью callback функции. А как раз такого варианта Amazon SQS не предлагает. Поэтому использование очереди для кроссдоменного взаимодействия невозможен.

Еще одна особенность - это необходимость иметь свой публичный и секретный ключ, который есть только у пользователей Amazon. Т.е. писать в очередь могут только пользователи сервисов от Amazon. Правда, тут есть возможность настроить анонимный доступ, но я им не пользовался пока и на сколько там все гладко сказать не могу.

С библиотеками тоже не все так просто, есть официальные библиотеки, которые работают без нареканий, но количество языков весьма ограничено - Java, PHP, Ruby. А есть библиотеки неофициальные, которые поддерживаются сообществом неравнадушных людей. Естественно, что никто не гарантирует работоспособность последних.

Для Erlang я нашел библиотеку, которая уже давно не поддерживается и для того, чтобы начать с ней работу пришлось немного допилить код. Но в любом случае подправить код лучше, чем писать его с нуля.

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

Но есть один большой недостаток, который для меня имеет решающее значение. Как я уже говорил - нельзя обращаться к очереди из браузера средствами JavaScript. Здесь, возможно, решением будет создание небольшого прокси-скрипта, который будет размещаться на моем сервере и с одной стороны получать JSONP запросы, а с другой обращаться к очереди, конвертируя результат в нужный формат. Но мне кажется, что уж проще сделать свой собственный простенький сервис сообщений, чем городить такой огород.

Ubuntu instance на Amazon EC2 или как можно выкинуть 350$ на ветер

Evgeny Sergeev — Tue, 24 Apr 2012 13:31:34 +0000

Уже писал про то, что хочу поиграться с Amazon Elastic Cloud. Сегодня, наконец-то, дошли руки до того чтобы создать свой инстанс. Так как за день набегался, то пошел простым путем - запустил на YouTube ролик по запуску Ubuntu Instance и тупо выполнил все шаги. В процессе установки затупил и в итоге потерял 350$. Сейчас расскажу как все получилось.

Ситуация следующая, при создании инстанса на EC2 можно выбрать готовый образ, который называется Amazon Machine Image (AMIs). Я наивно полагал, что это просто некий образ готовой гостевой системы. Но на самом деле в AMI может входить не только образ системы, но и некоторые дополнительные вещи. Например, Premium Support, которая в зависимости от тарифва (Bronze, Silver, Gold и т.д.) может стоить разных денег. Думаю, что вам не составит труда догадатсья, что, как самый последний лох на этой планете, я купил почти самую дорогую Silver поддержку, которая стоит 350$. Нет, я не жалуюсь, ведь все могло быть хуже - я мог купить Gold поддержку, которая еще дороже!

Не буду кривить душой и говорить, что во всем виноват буржуи, помешанные на прибыли. На самом деле, система меня мило предупредила, что у меня нет подписик на Premium Support и предложила перейти на страницу, где я смогу подключить данную услугу. В принципе, там было все подробно расписано, правда на буржуйском языке, но это сути дела не меняет. Так как я немного устал за день, то как-то сразу не сообразил, что за Premium Support я приобретаю. В итоге, подтвердив свое желание (о котором я даже не знал), я тут же получил СМС от банка, в котором говорилось что с моего счета списана определенная сумма денег… Всего-то навсего 350 баксов. В пересчете на русские деньги, естественно. После этого усталость сняло как рукой. Я еще раз внимательно прочитал, что именно подключаю и как-то сразу обратил внимание на то, что услуга Premium Support далеко не бесплатная. Но было уже поздно.

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

Будьте внимательны и не повторяйте моих ошибок.