Добрый день.
Когда Вы работаете с MySQL, то так или иначе Вам необходимо работать с записями, имеющими уникакльный ID.
Для ряда таблиц такого рода ID генерируется автоматически, путем использования директивы auto_increment.
Иногда необходимо знать, а какой же ID получился для только что добавленных данных ...
Сделать это можно просто, а именно воспользоваться встроенной в MySQL ф-й LAST_INSERT_ID(), которая возвращает ID добавленных данных.
Для примера:
mysql> SELECT LAST_INSERT_ID();
+------------------+
| LAST_INSERT_ID() |
+------------------+
| 33 |
+------------------+
1 row in set (0.00 sec)
Показывает, что последнаяя добавленная запись имела ID 33.
четверг, 16 июня 2011 г.
среда, 20 апреля 2011 г.
Java - собственные исключения
Добрый день.
Сегодня мы коротко поговорим о механизме исключений в Java.
Причем не просто о механизме как таковом, а о том, зачем необходимы собственные исключения и как их использовать на практике.
Итак - начнем с азов. Исключение (Java) — это некий объект, описывающий исключительное состояние, возникшее в каком-либо месте работы программы.
При этом (при возникновении исключения) создается объект класса Exception.
Затем может быть несколько вариантов развития событий:
1) Исключение не обрабатывается, то есть для данного участка кода нет обработчика соот. типа исключения.
В этом случае происходит завершение работы потока, в котором произошло исключение.
2) Исключение обрабатывается, и в этом случае управление передается в блок обработки исключений или-же в блок финализации.
Для примера:
try
{
// участок, где мы ожидаем исключение
}
catch (ИсключениеА еxt)
{
// обработчик Исключения А
}
catch (ИсключениеБ еxt)
{
// обработчик Исключения Б
}
finally
{
// блок финализации, который должен всегда выполняться.
}
Со стандартными исключениями все просто. Они определены и их обработка - это рутина
программирования.
Но в Java можно определять о обрабатывать свои исключения.
Сделано это по многим причинам, но одно из основных применений этой возможности
мы сейчас рассмотрим.
Итак - есть некое приложение, в котором есть некая процедура,
обрабатывающая некие, полученные извне, данные.
Так или иначе, данные могут быть некорректны (к примеру вместо число - строка и др.)и
состояние (некорректности входящих данных) необходимо обработать.
Это сделать можно множеством путей, одним из которых есть использование механизма
исключений.
// класс собственного исключения, описывающего некорректность пары ключ <> значение
class ParceError extends Exception
{
String KeyName,KeyValue;
// конструктор
ParceError(String inKeyName,String inKeyValue)
{
KeyName = inKeyName;
KeyValue = inKeyValue;
}
// конструктор по умолчанию
ParceError()
{
this("not","not");
}
// view
public String toString()
{
return "KeyName="+KeyName+" "+"KeyValue="+KeyValue;
}
}
// расшифровка ключей
// мы указываем, что наша процедура может генерировать исключение ParceError
// которое необходимо обработать
DecodeKeys(HashMap In,String Data) throws ParceError
{
// ..
// в случае некорректности некой пары ключ <> значение
// генерируем исключение
throw new ParceError(Key,Value);
// ..
}
try
{
Result = DecodeKeys(Result,Data);
}
catch (ParceError ext)
{
// обрабатываем сгенерированное исключение
}
То есть как видим, мы отделяем механизм обработки некорректности. Более того - мы из вызывающего метода не лезем в внутреннюю кухню проверки ...
Такого же рода меры можно применять при работе с различными событиями, для примера - обработку очередей и др.
Сегодня мы коротко поговорим о механизме исключений в Java.
Причем не просто о механизме как таковом, а о том, зачем необходимы собственные исключения и как их использовать на практике.
Итак - начнем с азов. Исключение (Java) — это некий объект, описывающий исключительное состояние, возникшее в каком-либо месте работы программы.
При этом (при возникновении исключения) создается объект класса Exception.
Затем может быть несколько вариантов развития событий:
1) Исключение не обрабатывается, то есть для данного участка кода нет обработчика соот. типа исключения.
В этом случае происходит завершение работы потока, в котором произошло исключение.
2) Исключение обрабатывается, и в этом случае управление передается в блок обработки исключений или-же в блок финализации.
Для примера:
try
{
// участок, где мы ожидаем исключение
}
catch (ИсключениеА еxt)
{
// обработчик Исключения А
}
catch (ИсключениеБ еxt)
{
// обработчик Исключения Б
}
finally
{
// блок финализации, который должен всегда выполняться.
}
Со стандартными исключениями все просто. Они определены и их обработка - это рутина
программирования.
Но в Java можно определять о обрабатывать свои исключения.
Сделано это по многим причинам, но одно из основных применений этой возможности
мы сейчас рассмотрим.
Итак - есть некое приложение, в котором есть некая процедура,
обрабатывающая некие, полученные извне, данные.
Так или иначе, данные могут быть некорректны (к примеру вместо число - строка и др.)и
состояние (некорректности входящих данных) необходимо обработать.
Это сделать можно множеством путей, одним из которых есть использование механизма
исключений.
// класс собственного исключения, описывающего некорректность пары ключ <> значение
class ParceError extends Exception
{
String KeyName,KeyValue;
// конструктор
ParceError(String inKeyName,String inKeyValue)
{
KeyName = inKeyName;
KeyValue = inKeyValue;
}
// конструктор по умолчанию
ParceError()
{
this("not","not");
}
// view
public String toString()
{
return "KeyName="+KeyName+" "+"KeyValue="+KeyValue;
}
}
// расшифровка ключей
// мы указываем, что наша процедура может генерировать исключение ParceError
// которое необходимо обработать
DecodeKeys(HashMap In,String Data) throws ParceError
{
// ..
// в случае некорректности некой пары ключ <> значение
// генерируем исключение
throw new ParceError(Key,Value);
// ..
}
try
{
Result = DecodeKeys(Result,Data);
}
catch (ParceError ext)
{
// обрабатываем сгенерированное исключение
}
То есть как видим, мы отделяем механизм обработки некорректности. Более того - мы из вызывающего метода не лезем в внутреннюю кухню проверки ...
Такого же рода меры можно применять при работе с различными событиями, для примера - обработку очередей и др.
четверг, 7 апреля 2011 г.
Java - поток демона (автоматическое завершение дочерних потоков)
Добрый день.
При программировании многопоточных приложений в Java очень часто стоит задача остановить потоки, которые являются дочерними.
Можно пойти 2-мя путями:
1) В ручном режиме "гасить" дочерние потоки.
2) Сделать это автоматически.
Про первый случай мы говорить не будем.
Поговорим про второй.
Для того, что-бы дочерние потоки завершались сами при завершении родительского потока,
необходимо дочерние потоки объявить как потоки демона.
Для примера:
Простой поток мы порождаем:
SimpleThread = new Thread(this,"Simple Thread");
SimpleThread.start();
Поток демона мы описывает так:
SimpleThread = new Thread(this,"Simple Thread");
SimpleThread.setDaemon(true);
SimpleThread.start();
Для проверки того, является ли поток потоком демона применяется метод isDaemon().
Возвращаемое значение - boolean.
Также необходимо пару слов сказать о области применения такого рода потоков. Чаще всего применять этот тип в том случае, когда отдельный поток должен делать некую работу, но только тогда, когда работает основное приложение.
Самый ходовой пример - менеджер заметок.
При программировании многопоточных приложений в Java очень часто стоит задача остановить потоки, которые являются дочерними.
Можно пойти 2-мя путями:
1) В ручном режиме "гасить" дочерние потоки.
2) Сделать это автоматически.
Про первый случай мы говорить не будем.
Поговорим про второй.
Для того, что-бы дочерние потоки завершались сами при завершении родительского потока,
необходимо дочерние потоки объявить как потоки демона.
Для примера:
Простой поток мы порождаем:
SimpleThread = new Thread(this,"Simple Thread");
SimpleThread.start();
Поток демона мы описывает так:
SimpleThread = new Thread(this,"Simple Thread");
SimpleThread.setDaemon(true);
SimpleThread.start();
Для проверки того, является ли поток потоком демона применяется метод isDaemon().
Возвращаемое значение - boolean.
Также необходимо пару слов сказать о области применения такого рода потоков. Чаще всего применять этот тип в том случае, когда отдельный поток должен делать некую работу, но только тогда, когда работает основное приложение.
Самый ходовой пример - менеджер заметок.
воскресенье, 21 ноября 2010 г.
Cisco - транскодирование
Добрый день.
Периодически возникает необходимость ответить на вопрос или найти документацию (с примерами) по некоторым вопросам, связанным с оборудованием Cisco.
Приведенные ниже ссылки, возможно, будут Вам полезны по вопросам, связанным с
транскодированием голосовых кодеков в MG cisco:
http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmetrnsc.html
http://www.cisco.com/en/US/docs/ios/12_3/vvf_c/interop/intcnf2.html
Периодически возникает необходимость ответить на вопрос или найти документацию (с примерами) по некоторым вопросам, связанным с оборудованием Cisco.
Приведенные ниже ссылки, возможно, будут Вам полезны по вопросам, связанным с
транскодированием голосовых кодеков в MG cisco:
http://www.cisco.com/en/US/docs/voice_ip_comm/cucme/admin/configuration/guide/cmetrnsc.html
http://www.cisco.com/en/US/docs/ios/12_3/vvf_c/interop/intcnf2.html
вторник, 21 сентября 2010 г.
Реализация услуги CLIR в протоколе SIP
Добрый день.
Наконец смог добавить сообщение.
Было очень много работы, причем частично дурной ... но живем.
Сегодня мы поговорим о том, как в протоколе SIP реализуется услуга CLIR.
Услуга CLIR (Calling line identification rebound) - запрет определения номера вызываемого абонента (А номер) позволяет абонентам совершать вызовы, не открывая при этом вызываемому абонента своего номера.
Теперь посмотрим как это работает в SIP.
Обычно протокол SIP оперирует А номером из заголовков From и Contact.
Для примера рассмотрим обычный INVITE:
INVITE sip:XXX56374XXXX@XX.XX.2.18:2000;user=phone SIP/2.0
From: "XXX56375XXXX";tag=1412239
To:;tag=9300128943591984131
Call-ID: 5C116F62-06E4-4501-B226-5BA0EF83EDD7
CSeq: 1 INVITE
Privacy: none
P-Asserted-Identity: tel:XXX56375XXXX
Max-Forwards: 69
P-Charging-Vector: icid-value=F593133B-AA95-4005-83A8-59CADB73407A
User-Agent: vocl-essentra-ex/8.1 (19070.34)
Via: SIP/2.0/UDP XX.XX.252.7:5060;received=XX.XX.252.7;branch=z9hG4bK-536856b0-4c9883a7;vtservice=b2buaservlet.siptosip
Contact:
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,INFO,PRACK
А теперь включим на нашем SSw (реализация достаточно однотипна, обычно называется примерно Caller ID Blocking) соот. услугу и посмотрим на INVITE:
INVITE sip:XXX56374XXXX@XX.XX.2.18:2000 SIP/2.0
From: "Anonymous";tag=1411481
To:;tag=9300128943591983723
Call-ID: 52588159-9C78-4F42-A67D-D5E4E284BAE7
CSeq: 1 INVITE
Privacy: id
P-Asserted-Identity: tel:XXX56375XXXX
Max-Forwards: 69
P-Charging-Vector: icid-value=77C422A6-6D56-4DBD-AAB5-410F7AA4EEAE
User-Agent: vocl-essentra-ex/8.1 (19070.34)
Via: SIP/2.0/UDP XX.XX.252.7:5060;received=XX.XX.252.7;branch=z9hG4bK-58251148-4c9881ab;vtservice=b2buaservlet.siptosip
Contact:
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,INFO,PRACK
Видите разницу ?
Во втором случае SSw "замаскировал" поля From и Contact.
Но при этом А номер сохранился в хитром поле P-Asserted-Identity.
Тем самым мы и маршрутизировать трафик можем по А номеру, и учет вести и при этом А номер сокрыт.
Наконец смог добавить сообщение.
Было очень много работы, причем частично дурной ... но живем.
Сегодня мы поговорим о том, как в протоколе SIP реализуется услуга CLIR.
Услуга CLIR (Calling line identification rebound) - запрет определения номера вызываемого абонента (А номер) позволяет абонентам совершать вызовы, не открывая при этом вызываемому абонента своего номера.
Теперь посмотрим как это работает в SIP.
Обычно протокол SIP оперирует А номером из заголовков From и Contact.
Для примера рассмотрим обычный INVITE:
INVITE sip:XXX56374XXXX@XX.XX.2.18:2000;user=phone SIP/2.0
From: "XXX56375XXXX"
To:
Call-ID: 5C116F62-06E4-4501-B226-5BA0EF83EDD7
CSeq: 1 INVITE
Privacy: none
P-Asserted-Identity: tel:XXX56375XXXX
Max-Forwards: 69
P-Charging-Vector: icid-value=F593133B-AA95-4005-83A8-59CADB73407A
User-Agent: vocl-essentra-ex/8.1 (19070.34)
Via: SIP/2.0/UDP XX.XX.252.7:5060;received=XX.XX.252.7;branch=z9hG4bK-536856b0-4c9883a7;vtservice=b2buaservlet.siptosip
Contact:
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,INFO,PRACK
А теперь включим на нашем SSw (реализация достаточно однотипна, обычно называется примерно Caller ID Blocking) соот. услугу и посмотрим на INVITE:
INVITE sip:XXX56374XXXX@XX.XX.2.18:2000 SIP/2.0
From: "Anonymous"
To:
Call-ID: 52588159-9C78-4F42-A67D-D5E4E284BAE7
CSeq: 1 INVITE
Privacy: id
P-Asserted-Identity: tel:XXX56375XXXX
Max-Forwards: 69
P-Charging-Vector: icid-value=77C422A6-6D56-4DBD-AAB5-410F7AA4EEAE
User-Agent: vocl-essentra-ex/8.1 (19070.34)
Via: SIP/2.0/UDP XX.XX.252.7:5060;received=XX.XX.252.7;branch=z9hG4bK-58251148-4c9881ab;vtservice=b2buaservlet.siptosip
Contact:
Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,INFO,PRACK
Видите разницу ?
Во втором случае SSw "замаскировал" поля From и Contact.
Но при этом А номер сохранился в хитром поле P-Asserted-Identity.
Тем самым мы и маршрутизировать трафик можем по А номеру, и учет вести и при этом А номер сокрыт.
вторник, 27 июля 2010 г.
Провал в головах или WIMax по украински
Добрый всем вечер.
Сегодня мы немного затронем тему WiMax.
А вернее - его якобы "провала".
Итак на днях на ряде сайтов, стали активном цитировать газету "Дело", которая выступила с плаксивой статьей, суть которой сводиться к тому, что внедрение WiMAx потерпело неудачу.
(для примера - http://www.broadband.org.ua/content/view/2519/490/).
В сухом остатке из этого текста мы узнаем, что:
Внедрение WiMAx провалено, по причине якобы плохой технологии, злого УТ и развращенных пользователей.
На лицо яркий пример подмены понятий, когда неумение планировать и руководить пытаются замаскировать.
Итак постараемся разобрать почему я говорю именно в таком ключе.
Разберем тезис N1:
"Первый и основной фактор, объясняющий такое положение вещей, — это несовершенство технологии, которая требует установки большего количества базовых станций.Но даже это не решит проблемы: львиная доля абонентов WiMax постоянно испытывают сложности с наличием сигнала в помещении, и эти проблемы не всегда решаются размещением модемов, например, на балконе. "
Какая жалость.
То есть налицо ситуация, когда сеть построена таким образом, что сигнала в зданиях нет.
Иначе говоря на этапе проектировки и тестирования никто не озаботился проверкой того, а будет ли ЭТО работать в зданиях. И мы сразу понимаем, что:
а) проектировка велась небрежно, без учета особенностей технологии.
б) тестирование в необходимом объеме не проводилось.
Зато по документам все красиво - 70% типа "покрыто".
Есть еще еще одно предположение .... страшное, но тоже не менее логичное.
На этапе составления бизнес плана неверно была выбрана аудитория и не учтены условия.
То есть великие аналитики предположили, что 100К человек купят WiMAx и дружно выйдут на улицу.
Правда в этом случае, как минимум, не учтен наш климат, ибо летом у нас жарко, зимой холодно, осенью сыро и холодно, а весной тоже погода далеко не всегда балует.
Кроме того, если программист может себе позволить поваляться на травке, то для ряда работников ра-ть на улице просто недопустимо.
Проще говоря имела место попытка подогнать не технологию под человека, а человека под технологию.
Читаем дальше и удивляемся:
"Российские 4G-операторы для решения этой проблемы используют специальное оборудование, устанавливаемое в помещениях и усиливающее мощность сигнала. Но этот путь требует значительных денежных вложений, окупаемость которых в нынешней ситуации не гарантирована."
То есть еще одно подтверждение того, что никто не удосужился разобраться с особенностями работы технологии. Если бы разобрались, то воспользовались опытом Yot'ы и установили внутренние усилители, тем самым покрыв бы 30% Киева зоной уверенного приема и получили бы довольных абонентов, которых было-бы намного больше, чем теперь.
"Также более чем скромное число абонентов объясняется тем, что обе компании предлагают клиентам USB-модемы по льготной цене только при условии подписания годичного контракта."
Комментировать это вообще трудно .... тут бы разобраться, кто является основной клиентской базы для такого рода услуги. И после чего понять, что люди, которые выбирают этот вид связи (в основном абоненты, ориентированные на бизнес) привыкли к прогнозируемым расходам в любом виде деятельности (в том числе в связи).
"Помимо этого, тарифные планы двух компаний — безлимитные пакеты стоят 150-180 грн. в месяц — на фоне постоянного удешевления предложений у других провайдеров Интернета выглядят довольно дорогостоящими. "
Тоже перл неслабый. А за что получали деньги составители бизнес плана ? За трезвый анализ и соот. прогнозирование тарифов или сидение в кожаных креслах ?
Иначе говоря - явных провал составителей бизнес плана.
Если бы при составлении бизнес плана был учтен опыт стационарной связи и коллег из соседних стран, то и тарифы и методы построения сети имели бы совершенно иной вид.
Итого что мы имеем - явный провал на этапе проектирования и тестирования.
И никаких попыток исправить ситуацию при запуске.
То есть группа людей составила красивый прожект, получила под него деньги (а вложено уже 50 млн. $) и по факту эти деньги выброшены на ветер (это в лучшем случае, а в при более пессимистичном прогнозе - распилены).
И откровенно говоря, вероятной причиной появления данной статьи стало то, что те ,кто провалил внедрение прожекта, попытались тем самым оправдаться .. мол мы не виноваты, обстоятельства такие.
Иначе говоря облажавшиеся топ менеджеры (небось с дипломами MBA) ищут способы уйти от ответа (что в целом типично для обычного топа).
А если серьезно, то WiMax конечно не самая лучшая технология (к слову называть ее 4G - неграмотно), но при грамотнои проектировании сети вполне себе работает вполне хорошо.
Именно поэтому сегодня Киевстар с помощью S&T Ukraine строит WiMax сеть, которая ориентирована на СТАЦИОНАРНЫЙ доступ, что четко показывает что в VimpelTelecom Ltd. сидят не дураки, понимающие нужды клиентов.
А тем кто хочет именно WiMAx, стоит чуть потерпеть и получить качественный беспроводный доступ.
Или-же не замыкаться на технологии,а выбрать достойные альтернативы, которых на Украине немало.
Сегодня мы немного затронем тему WiMax.
А вернее - его якобы "провала".
Итак на днях на ряде сайтов, стали активном цитировать газету "Дело", которая выступила с плаксивой статьей, суть которой сводиться к тому, что внедрение WiMAx потерпело неудачу.
(для примера - http://www.broadband.org.ua/content/view/2519/490/).
В сухом остатке из этого текста мы узнаем, что:
Внедрение WiMAx провалено, по причине якобы плохой технологии, злого УТ и развращенных пользователей.
На лицо яркий пример подмены понятий, когда неумение планировать и руководить пытаются замаскировать.
Итак постараемся разобрать почему я говорю именно в таком ключе.
Разберем тезис N1:
"Первый и основной фактор, объясняющий такое положение вещей, — это несовершенство технологии, которая требует установки большего количества базовых станций.Но даже это не решит проблемы: львиная доля абонентов WiMax постоянно испытывают сложности с наличием сигнала в помещении, и эти проблемы не всегда решаются размещением модемов, например, на балконе. "
Какая жалость.
То есть налицо ситуация, когда сеть построена таким образом, что сигнала в зданиях нет.
Иначе говоря на этапе проектировки и тестирования никто не озаботился проверкой того, а будет ли ЭТО работать в зданиях. И мы сразу понимаем, что:
а) проектировка велась небрежно, без учета особенностей технологии.
б) тестирование в необходимом объеме не проводилось.
Зато по документам все красиво - 70% типа "покрыто".
Есть еще еще одно предположение .... страшное, но тоже не менее логичное.
На этапе составления бизнес плана неверно была выбрана аудитория и не учтены условия.
То есть великие аналитики предположили, что 100К человек купят WiMAx и дружно выйдут на улицу.
Правда в этом случае, как минимум, не учтен наш климат, ибо летом у нас жарко, зимой холодно, осенью сыро и холодно, а весной тоже погода далеко не всегда балует.
Кроме того, если программист может себе позволить поваляться на травке, то для ряда работников ра-ть на улице просто недопустимо.
Проще говоря имела место попытка подогнать не технологию под человека, а человека под технологию.
Читаем дальше и удивляемся:
"Российские 4G-операторы для решения этой проблемы используют специальное оборудование, устанавливаемое в помещениях и усиливающее мощность сигнала. Но этот путь требует значительных денежных вложений, окупаемость которых в нынешней ситуации не гарантирована."
То есть еще одно подтверждение того, что никто не удосужился разобраться с особенностями работы технологии. Если бы разобрались, то воспользовались опытом Yot'ы и установили внутренние усилители, тем самым покрыв бы 30% Киева зоной уверенного приема и получили бы довольных абонентов, которых было-бы намного больше, чем теперь.
"Также более чем скромное число абонентов объясняется тем, что обе компании предлагают клиентам USB-модемы по льготной цене только при условии подписания годичного контракта."
Комментировать это вообще трудно .... тут бы разобраться, кто является основной клиентской базы для такого рода услуги. И после чего понять, что люди, которые выбирают этот вид связи (в основном абоненты, ориентированные на бизнес) привыкли к прогнозируемым расходам в любом виде деятельности (в том числе в связи).
"Помимо этого, тарифные планы двух компаний — безлимитные пакеты стоят 150-180 грн. в месяц — на фоне постоянного удешевления предложений у других провайдеров Интернета выглядят довольно дорогостоящими. "
Тоже перл неслабый. А за что получали деньги составители бизнес плана ? За трезвый анализ и соот. прогнозирование тарифов или сидение в кожаных креслах ?
Иначе говоря - явных провал составителей бизнес плана.
Если бы при составлении бизнес плана был учтен опыт стационарной связи и коллег из соседних стран, то и тарифы и методы построения сети имели бы совершенно иной вид.
Итого что мы имеем - явный провал на этапе проектирования и тестирования.
И никаких попыток исправить ситуацию при запуске.
То есть группа людей составила красивый прожект, получила под него деньги (а вложено уже 50 млн. $) и по факту эти деньги выброшены на ветер (это в лучшем случае, а в при более пессимистичном прогнозе - распилены).
И откровенно говоря, вероятной причиной появления данной статьи стало то, что те ,кто провалил внедрение прожекта, попытались тем самым оправдаться .. мол мы не виноваты, обстоятельства такие.
Иначе говоря облажавшиеся топ менеджеры (небось с дипломами MBA) ищут способы уйти от ответа (что в целом типично для обычного топа).
А если серьезно, то WiMax конечно не самая лучшая технология (к слову называть ее 4G - неграмотно), но при грамотнои проектировании сети вполне себе работает вполне хорошо.
Именно поэтому сегодня Киевстар с помощью S&T Ukraine строит WiMax сеть, которая ориентирована на СТАЦИОНАРНЫЙ доступ, что четко показывает что в VimpelTelecom Ltd. сидят не дураки, понимающие нужды клиентов.
А тем кто хочет именно WiMAx, стоит чуть потерпеть и получить качественный беспроводный доступ.
Или-же не замыкаться на технологии,а выбрать достойные альтернативы, которых на Украине немало.
среда, 14 июля 2010 г.
Шаг вперед или свет в конце тоннеля
Добрый день всем.
Давненько я не писал - не было времени, уж очень тяжелые последние дней 10 выдались.
Итак главное и очень позитивное событие последних 2-х недель - это принятие Верховным Советом в первом чтении законов, которые расширяю полномочия НКРС.
По ККЭ (кабельная канализация элекстросвязи) дает право НКРС регулировать тарифы и порядок доступа к ККЭ.
Кроме ККЭ, взялись решать вопрос с Интерконнеком.
Для этого вводиться понятие оператора с "существенным рыночным положением", тарифы которого (прежде всего на взаимосоединение) можно будет регулировать.
Иэ этого события можно сделать 2 вывода:
1) УТ таки хотят продать, потому как если до продажи не утрясти вопрос с канализацией, то могут проявиться различные неприятные моменты.
2) Есть все-же шанс, что наш рынок связи выйдет из того анархического болота, в котором он сидел последние 5 лет и больше не будут повторяться ситуации, когда с номеров Оператора А мы не можем позвонить на Оператора Б, а все потому, что они не договорились о том, кто и сколько кому должен.
Если же кому-то кажется, что подобное гос. регулирование мешает нормальному развитию рынка, то для примера возьмите и ознакомьтесь с механизмами гос. регулирования связи в Китае, ЕС, и США.
Суть в том, что вседозволенности и анархии быть НЕ должно.
Кроме того, прошел более чем обоснованный слух о том, что стоимость нового плана конверсии (предположительно готов будет в акгусте)частот от МО будет порядка 850 млн. грн.
Это почти в три раза меньше прошлогодней цифры.
То есть при этом мы получаем вполне реальный шанс провести полноценный тендер на частоты для 3G уже в этом году.
Давненько я не писал - не было времени, уж очень тяжелые последние дней 10 выдались.
Итак главное и очень позитивное событие последних 2-х недель - это принятие Верховным Советом в первом чтении законов, которые расширяю полномочия НКРС.
По ККЭ (кабельная канализация элекстросвязи) дает право НКРС регулировать тарифы и порядок доступа к ККЭ.
Кроме ККЭ, взялись решать вопрос с Интерконнеком.
Для этого вводиться понятие оператора с "существенным рыночным положением", тарифы которого (прежде всего на взаимосоединение) можно будет регулировать.
Иэ этого события можно сделать 2 вывода:
1) УТ таки хотят продать, потому как если до продажи не утрясти вопрос с канализацией, то могут проявиться различные неприятные моменты.
2) Есть все-же шанс, что наш рынок связи выйдет из того анархического болота, в котором он сидел последние 5 лет и больше не будут повторяться ситуации, когда с номеров Оператора А мы не можем позвонить на Оператора Б, а все потому, что они не договорились о том, кто и сколько кому должен.
Если же кому-то кажется, что подобное гос. регулирование мешает нормальному развитию рынка, то для примера возьмите и ознакомьтесь с механизмами гос. регулирования связи в Китае, ЕС, и США.
Суть в том, что вседозволенности и анархии быть НЕ должно.
Кроме того, прошел более чем обоснованный слух о том, что стоимость нового плана конверсии (предположительно готов будет в акгусте)частот от МО будет порядка 850 млн. грн.
Это почти в три раза меньше прошлогодней цифры.
То есть при этом мы получаем вполне реальный шанс провести полноценный тендер на частоты для 3G уже в этом году.
Подписаться на:
Сообщения (Atom)