NDC – это National Destination Code

И никак не “Network Destination Code”, и никак не “Normalized Device Coordinates” и уж точно никак не National Drug Code.

Надеюсь хоть сейчас запомню.

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

В пресс-релизе утверждается, что это пока бета-версия, оптимизированная под iPhone, и разработка её активно ведется.

Исходя из собственного опыта использования LinkedIn, придумать success-story использования мобильной версии мне не удалось. Скорее всего разработчики “повелись” на всеобщуюю истерию iPhone-омании, а возможно тут приложился “кулуарный монстр” Стив Джобс.

P.S. Для себя отметил очень неплохой уровень технической реализации мобильной версии.

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

Для начала несколько вводных терминов:

Контент – это все что можно отдать/продать абоненту (мелодии, картинки, игры, приложения, SMS, MMS, WAP-страницы, и тд)

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

Премиум номера – SMS/MMS-номера со стомостью сверх стандартной

Разделение трафика/стоимости – процесс “деребана” денег, полученных от абонента за контент услуги между оператором и провайдером.

Итак…

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

2. Недовольный абонент (а в случае лохотрона таких ровно 100%) – это прямые и косвенные затраты и контент-провайдера и оператора.
Прямые – затраты на службу поддержки (как провайдера так и оператора), потери от нелояльности абонента,…
Косвеные – портятся отношения с оператором, который в свою очередь тоже имеет прямые затраты от неудач провайдеров.

Миф 2 – Они продают воздух
На самом деле за каждой контентной единицей, продаваемой контент-провайдером, стоит огромный труд техников, менеджеров, пиарщиков, рекламистов, юристов.
Провайдер, который пытается продать контент, не имея документального подтверждения прав на него, рискует “попасть” на крупную сумму + судебные издержки.
Примеров судов над медиа-пиратами даже на украинском рынке хватает.
Также часто слышу мнение, что услугами контент-провайдеров никто не пользуется, и что они отживают свое – ежегодный рост контент-рынка во всем мире убеждает в обратном.

Миф 3 – У них необоснованно высокие цены
На самом деле часть дохода, которую получает контент-провайдер от стоимости, заплаченной абонентом за услугу, ничтожно мала.
И живут контент-провайдеры в основном за счет широкой аудитории пользователей услуг.
Для примера: с каждого SMS-сообщения, которое отправляет абонент на премиум-номер, 50% (а иногда и все 75%) получает оператор, с остальных 50% контент-провайдер платит отчисления по авторским правам, роялти (читай миф 2), и отчисления субконтент-провайдерам – в результате остается у бедного провайдера совсем небольшой процент на который нужно оплачивать рекламу, оборудование, зарплату специалистов, аренду офиса и тд.
И тем не менее ни российские, ни украиские крупные(!) контент-провайдеры особо не бедствуют:)

Миф 4 – Пробовал я – нифига у них не работает!
Опыт показывает, что 90% ошибок и сбоев при получении абонентом услуги происходит по ошибке абонента: не настроен WAP, невнимательно читает, невнимательно вводит, и тд…
Остальные 10% можно поровну разделить между технологическими сбоями на стороне операторов и контент-провайдеров.
Очень немаловажной причиной остается низкий уровень базовых технических знаний у старшего слоя пользователей услуг.

Миф 5 – Пробиться в эту сферу нереально
Витает миф, что бизнес контент-провайдеров доступен только ограниченному кругу приближенных лиц.
Спешу заверить, что это не так. Спрос на новые решения со стороны операторов на рынке дополнительных услуг очень велик, также существует много ещё незанятых как технологических, так и маркетинговых ниш в этой сфере.
Большинство теперешних топ-контент-провайдеров вышли на рынок и смогли удержаться с одной, но уникальной, услугой.
Так что, если есть интересные идеи – дерзайте! – Никаких сверх-технологий и сверх-идей тут не нужно. Все достаточно просто и банально.
Если будет интересно, то как-нибудь напишу заметку о том, как легко стать небольшим контент-провайдером и зарабатывать на SMS-услугах.

Надеюсь мне удалось немного разогнать тучи недоверия, которые витают над деятельностью контент-провайдеров.

Что меня больше всего поразило – так это рассказ о перезентации 3G связи от Utel.
Докладчик вышел на сцену, со словами а-ля “я тут буду проводить презентацию, но только у меня нет компьютера”.
Далее с невозмутимым видом подключает к проектору телефон Nokia N95 и начинает вживую демонстрировать преимущества 3G-связи: делает видеозвонок своему ассистенту за пределами зала, проводит видеозвонок на UMTS видеокамеру и тд.

Конечно демонстрируя 3G вживую, докладчик сильно рисковал, нарушая “золотое правило презентаций” – не проводить презентацию online, “по живому” (меня этому ещё в универе научил ВПШ).
Но эффект от такой демонстрации по сравнению с привычным “слайды+текст+голос”, был просто потрясающим!

И в завершение обязательная к прочтению статья Антона Антича “Как делать хорошие презентации“.

_________
Ссылки по теме:
Вот как надо предлагать вакансию!
А вот так не надо предлагать вакансию

Работал этот товарищ администратором серверов в одной компании, близкой телекоммуникационному рынку.
А сервера те были не простые, а с очень высокими требованиями по доступности услуг, на них размещенных.
Потому, дабы быть в курсе всего, что с оными серверами происходит, настроил он мониторинговую систему.
Да так настроил, что она ему присылала SMS-сообщения (напомню что компания имела отношение к телекоммуникациям) при малейшей внештатной ситуации.
Поскольку SMS-сообщения приходили с номера, на котором тарифицировалось только исходящее от абонента сообщение (так называемая MO-тарификация), то для нашего героя получение этих SMS по карману не било.

Общеизвестно, что системные администраторы в большинстве своем техноманы.
И был у этого товарища смартфон на Windows Mobile (умный такой, производительный), на котором он настроил 2 простые, но тем не менее очень удобные “рюшечки”.
1. После 21:00 переходить в Silent Mode
2. Если после 21:00 телефон находится в пределах GSM-вышки, которая обслуживает микрорайон его обитания, — на все входящие звонки и сообщения отвечать SMS-сообщением “Извините, не могу говорить. Я вам перезвоню утром.”

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

Далее со слов друга:

“Проспаюсь в 3 часа ночи от входящей SMS, думаю “опять что-то сломалось”, читаю SMS от мониторинговой системы с русским текстом “Ты спишь?”, ничего не понимаю, пинаю на сглючивший телефон, сплю дальше.
Через минут 15-20 получаю повторное сообщение “Почему молчишь?”. Волосы начинают медленно шевелиться на голове, беру ноутук, и тихо, чтоб никого не разбудить пробирась на кухню в надежде все-таки узнать почему сработали мониторинговые триггеры.
По пути на кухню получаю “Тебе со мной интересно?”
О-да! Ещё как интересно!
Рука нервно тянется к холодильнику в поисках недопитого женой бейлиса, а мозг упрямо твердит “Меняй работу! Вот видишь, доигрался! Меняй работу!”.
Не успев даже открыть ноутбук получаю ещё одно “Зачем ждать утро – звони сейчас!”.
И тут до меня начинает медленно доходить что произошло…”

В итоге, получилось, что мониторинг отреагировал на внештатную ситуацию на сервере, честно отправил SMS моему товарищу. Его же телефон, получив входящую SMS-ку, и проверив время суток, и по номеру соты свое местоположение – отправил ответное (тарифицируемое) сообщение “Извините, не могу говорить. Я вам перезвоню утром.”, которое в свою очередь попало операторам описанной выше услуги.
Те же, пользуясь “золотым правилом” SMS-услуг – честно отправили осмысленный ответ.
И так по кругу…

В итоге товарищ “наобщался” с мониторингом на кругленькую сумму, а про SMS-автоответчики даже вспоминать боится…

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

Как и обещал выкладываю свою презентацию о Groovy и текст черновика-шпаргалки в нему.

Groovy – другой взгляд на Java
Текст шпаргалки

Буду благодарен за любые отзывы, советы, указания ошибок в моем выступлении – активно идем к совершенству:)

И конечно с нетерпением ждем видеозапись встречи от Димы.

Операторы мобильной связи нарушают закон, рассылая абонентам смс на латинице. К такому выводу пришла Россвязьохранкультура, выборочно проверив нескольких операторов. Закон «О связи» предусматривает, что взаимоотношения операторов с абонентами на территории России должны осуществляться на русском языке, говорится в сообщении ведомства. По закону «О языках народов РФ» алфавиты государственного языка России и республик строятся на основе кириллицы, поэтому использование в смс латиницы является нарушением, которое операторам предписано устранить.

Первым отреагировал “Билайн”, разослав VASP-партнерам уведомление о необходимости “перевести” услуги “обратно на русский язык”.
Некоторые VASP-партнеры, идя по пути наименьшего сопротивления попросту на своих шлюзах проводят принудительную транслитерацию транслит-в-русский.
С одной стороны мне такое преобразование показалось странным и достаточно неоднозначным, но как оказалось все достаточно ясно, т.к. для обратная транслитерация проходила согласно стандартам ГОСТ.

Собственно себе на заметку (а также разработчикам мобильных услуг) привожу таблицу транслитерации ГОСТ:

Понимание системных потоков MIDP

Оригинал, By Eric Giguere, December 2004

Параллелизм (concurrency) – многопоточное одновременное исполнение внутри одного приложения – обширная тема. Не смотря на то, что технология Java всегда содержала исчерпывающую встроенную поддержку многопоточности, написание правильного «параллельного» кода редко оказывается таким простым, как кажется. Чтоб немного помочь разработчику, J2SE 5.0 предлагает множество «параллельных» утилит, базирующихся на работе Дага Ли (Doug Lea), автора «Параллельное программирование в Java » (Concurrent Programming in Java) – превосходного справочника, какой стоит прочесть каждому. К сожалению, эти новые классы не доступны для J2ME-приложений, но основные приемы описанные в статье “Using Threads in J2ME Applications”, не изменятся. Эти технические советы фокусируют внимание на использовании системных потоков (system threads) в контексте MIDP-программирования, где спотыкаются множество новичков.

Системный поток (system thread) – это любой поток, что не был запущен и не управляется приложением. В среде MIDP, системные потоки создаются системой управления приложениями (Application Management Software – AMS), которая контролирует выполнение MIDлета. Каждое активное приложение имеет как минимум один системный и ноль или более собственных потоков.

Обратите внимание на это «как минимум»! Реализация может использовать несколько системных потоков для разных операций или, если необходимо, для разделения системных потоков между несколькими MIDлетами опираясь на «песочницу» (sandbox) MIDлета и другие ограничения. Спецификация MIDP не дает гарантий относительно того, какой и сколько потоков AMS использует для выполнения конкретной операции.

Рассмотрим процесс создания MIDлета. AMS может использовать код, подобный этому для загрузки и выполнения MIDлета.
[java]

// Load and start a MIDlet
String name = readMIDletName();
MIDlet m = null;
try {
  m = (MIDlet) Class.forName( name ).newInstance();
  registerMIDlet( m );
} catch( Throwable e ) {
  abortMIDlet( name, m );
}

[/java]
Проблема этого подхода заключается в том, что если MIDлет «замрет» во время создания или старта, AMS будет заблокирована также. Более параноидальные AMS порождают новый поток для загрузки и старта MIDлета. Тогда они ожидают окончания инициализации или ждут определенное разумное время. MIDлет не имеет возможности самостоятельно контролировать процесс запуска, потому лучшая стратегия для разработчика – удостовериться что конструктор и метод startApp() выполняются быстро и без блокировок.

Вероятнее всего MIDлеты блокируются когда они уже загружены и запущены. AMS использует системные потоки для доставки событий и уведомлений приложению. Опять же нету никаких гарантий, что они были доставлены одним потоком, что на практике чаще всего и происходит. AMS доставляет их прямо в MIDлет путем вызова методов из разных объектов. Например, AMS вызывает метод paint() экземпляра класса Canvas только тогда, когда холст (canvas) должен быть перерисован.

AMS эффективно устраняется от управления потоком, выполняя нотификации. Чтобы удостовериться что система продолжает работать нормально, поведение MIDлета подчиняется «негласному договору» между ним и AMS. Зависимость содержит 2 простых, одинаково важных, части: быстрое выполнение, отсутствие блокировок. Первая часть говорит что MIDлет должен обрабатывать события и уведомления так быстро, как только можно и таким образом сразу возвращать управление потоком. Вторая часть указывает MIDлет не блокировать системный поток выполняя доставку.

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

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

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

Два действия могут легко ожидать окончания друг друга бесконечно, даже в этой безвредно-выглядящей части кода:
[java]

String url = ...
Connection conn = null;
try {
  conn = Connector.open( url );
  // do something here
} catch( IOException e ) {
  // error
}

[/java]
Ядро проблемы – это «блокировочная» природа вызова open(). На некоторых платформах система «держит» все активные подключения в отдельном потоке. Вызывается блокировка потока пока другой поток выполняет соединение. В это же время подсистема безопасности может запросить у пользователя подтверждение выполнения соединения, и поток подключения будет заблокирован до момента, пока поток событий не получит подтверждение от пользователя. Взаимная блокировка происходит потому что поток событий ждёт окончания работы потока соединения.

Для решения подобных проблем, лучшим подходом является перенос блокирующих действий в отдельный поток, созданный приложением. Это усложняет программирование приложения, но при долгих запусках – это безопасное решение. Пример реализации такого подхода ищите в статье “Making HTTP Connections Using Background Threads”.

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

I’m was wonderin’ when see that Asterisk (*) can execute compiled .NET files as extension and dialplan schema.

AGI is Asterisk Gateway interface. It can be used to extend asterisk functionalities with help of different programming/scripting languages like C#, Perl, PHP etc.

For start the first thing you need to have installed in your box is Mono Tone. That is an open source project to use .NET Framework in Linux.

You can download Mono-Tone from http://www.mono-project.com/Downloads.

After installing you can use .NET assemblies and execute .exe files. You can compile any C# files with – mcs command line which is equivalent to csc in Windows. And you can run .exe file with mono command. But wait! Don’t go too fast because although you can run .exe file using mono command in Mono Project but AGI won’t execute your executables using mono. Asterisk and your .NET assembly share same console so you need to pass data from your program directly to Asterisk. You need to do some configurations to be able to run .NET assemblies directly and without mono command. For that you need to configure your binfmt. You can find the configuration HERE. (Find solution under Can I run Mono applications without using ‘mono program.exe’?

After that if you plan to restart your box in order to have same configuration after entry you need to add same configuration to /etc/rc.local

You need to place monotone.dll and your .net assemblies in /var/lib/asterisk/agi-bin/ and your sound files (in .gsm format) in /var/lib/asterisk/sounds/.

Now you are ready to start with your first program.

Называют это возможностю создать своего виртульаного мобильного оператора (Mobile Virtual Network Operator – MVNO).
Насколько я понял тут идет речь об аутсорсинге контент-провадерских услуг.
Причем не в принятом нынче примитивном виде суб-контент-провайдерства, а-ля “давайте мы ваши картиночки и мелодии продадим по нашим каналам сбыта, а вы с нам поделитесь доходом”.

Тут концепцию можно развивать куда интереснее:

• Хочешь продавать свои Java приложения на своем же ресурсе – зашел в web-морду, потыкал кнопочки – есть метод заказа по СМС, есть wap- промо-сайтик и ссылка для загрузки, есть PayPerclick-оплата, есть раздача демо-версии направо-налево …
• Хочешь свой wap-портал – разворачиваешь DNS на наше оборудование, ставишь галочки – хочу погоду, хочу расписание кинотеатров для Токио и для Киева, хочу банерную рекламу каждого раздела по очереди, и не забываем про формочку Feedback-а и поиск… Добавляем ко всему этому свои шаблоны и вуаля!
• Хочешь просмотр видео, продажу MP3-музыки, изображений – ставь галочку, грузи контент(или выбирай из доступного) – а платформа сама за тебя подумает и проведет адаптацию этого контента – все довольны все счастливы.
• Хочешь мобильное комьюнити, со своим файлообменником, и внутренним мессенджером over Wireless Village или XMMP – нефиг делать, только галочку поставь. И за премиум аккаунты в этом комьюнити денюжку не забывай брать с самых ярых юзеров.
• Хочешь промо-акцию с кодами на крышечках от кока-пива? Вгружай коды, выбирай механику акции (благо таких сценариев раз-два и обчелся) и беги искать крышечку чтоб стать первым абонентом…
• и тут Остапа понесло….

А самое главное…
И за все это дело не забудь платить некую абон-плату и часть дохода от трафика (wap, SMS, другое, – нужное подчеркнуть).

В результате такая себе коробочная версия контент-провайдера.
Почему бы и нет? Есть же коробочные версии всяких VASP-подуктов, причем иногда даже с 19-дюймовой железякой поставляются.
А все это к тому, что Sonopia работает в Украине тоже, и возможно в обозримом будущем небольшие контент-провадеры начнут “потерпать” от нехватки мелкого заказчика, какой предпочтет не самый гибкий, но дешевый mainstream, более дорогой разработке “под ключ”.

Остается открытым уже юридический вопрос: КТО БУДЕТ ОТВЕЧАТЬ ЗА КАЧЕСТВО И ЗАКОННОСТЬ КОНТЕНТА?
С одной стороны права на контент каждый получать не будет – слишком пыльное это дело, потому прийдется либо брать контент без спросу, либо арендовать у провайдера.
Ввиду того что большие контент-провайдеры своей репутацией дорожат – с пиратами сотрудничать не захочет никто. Следовательно контент прийдется брать у контента провайдера (опять же за деньги). А т.к. контент принадлежит контент провадеру – то и за его качество и законность он и отвечает.

Кстати тут интереснее об этом.

Updated: А вот уже сделаны первые шаги.