Комментарии 90
Интересно, конечно, но маловато технических/функциональных подробностей. Что, кроме языка программирования, отличает ее от всех остальных?
Скажу так, Smalltalk даёт нам главное конкурентное преимущество — скорость разработки при гарантированном качестве (TDD).
С удовольствием расскажу о технических подробностях. Что вас интересует? Предбиллинг, Cisco-Radius, Netflow? Подробности реализации ядра биллинга? Интеграция с платёжными системами?
С удовольствием расскажу о технических подробностях. Что вас интересует? Предбиллинг, Cisco-Radius, Netflow? Подробности реализации ядра биллинга? Интеграция с платёжными системами?
Интересно все, я с разработкой БС знаком не по-наслышке, по-этому интересно посмотреть как это делают другие :) Но некоторые вопросы меня интересую больше других:
Из чего состоит предбиллинг, какой механизм обеспечивает актуальность информации которая в нем хранится?
Умеет ли система работать с Cisco ISG, если да, то ограничивается ли ее интеграция предбиллингом или он таки «вжился» глубже?
А почему «Cisco-Radius»? Или под этим «термином» прячется что-то типа упомянутого SSG/ISG?
А это уже не совсем вопрос, скорее недоумение: нафига в биллинге NetFlow?!?
Из чего состоит предбиллинг, какой механизм обеспечивает актуальность информации которая в нем хранится?
Умеет ли система работать с Cisco ISG, если да, то ограничивается ли ее интеграция предбиллингом или он таки «вжился» глубже?
А почему «Cisco-Radius»? Или под этим «термином» прячется что-то типа упомянутого SSG/ISG?
А это уже не совсем вопрос, скорее недоумение: нафига в биллинге NetFlow?!?
Предбиллинг широкополосного доступа (видимо он интересует в первую очередь) состоит из самописного Radius, который авторизует пользователей и забирает трафик с сервера доступа, как правило Cisco. Актуальность данных авторизации обеспечивается ядром биллинга.
С Cisco ISG не работает.
NetFlow, как и IP Accounting — способы учета трафика.
С Cisco ISG не работает.
NetFlow, как и IP Accounting — способы учета трафика.
Самописный Radius-сервер это лихо, тоже на SmallTalk? ;)
Мы давно пришли к выводу (а в Cisco по-моему всегда так думали), что использовать NetFlow для учета трафика очень неудобно. Все данные и него в SQL не запихаеш, а использовать для него отдельный агрегатор — лишнее, часто очень ненадежное, звено.
IP accounting, NetFlow, Radius — предбиллингу есть чем занятся :) При использовании ISG все гораздо проще.
Мы давно пришли к выводу (а в Cisco по-моему всегда так думали), что использовать NetFlow для учета трафика очень неудобно. Все данные и него в SQL не запихаеш, а использовать для него отдельный агрегатор — лишнее, часто очень ненадежное, звено.
IP accounting, NetFlow, Radius — предбиллингу есть чем занятся :) При использовании ISG все гораздо проще.
Я однажды попал в аналогичную ситуацию — пригласили сетевым консультантом в один крупный (но провинциальный :) банк. Год был 1997й. Программисты в банке — московские. И вот им видимо надоели всякие FoxPro, решили сбацать что-то крутое. И тоже взяли Smalltalk. Купили VisualWorks фирмы ParkPlace-Digitalk — самый по тем временам навороченный (Dolphin Smalltalk тогда еще был в виде самых первых бет, крайне сырой и глюкавый, Squeak Smalltalk'а кажется еще вовсе не было, а у VisualWorks лет 10-15 за плечами — на разных платформах). Меня позвали на стадии, когда они уже несколько месяцев с ним баловались, сделали прозрачное отображение всей объектной иерархии в Oracle-сервер, какие-то прототипы интерфейса, и много чего еще интересного. Но собственно в целевой задаче почти не продвинулись. Я походил тогда на их рабочие совещания, послушал, сделал вывод, что ничего у них при таком подходе не выйдет (не из-за Смолтолка, а по организационным причинам скорее), и что проект уже не спасти. На этом моя миссия там и завершилась. Новую систему они там так и не запустили, продолжали работать в старой DOS-овой, а после кризиса 98го всех разогнали, купили какую-то готовую московскую систему (за космическую сумму), и всё.
А Смолтолк с тех пор мой любимый язык. Вместе с Лиспом. Правда я ничего крупнее самодельного веб-сервера на Смолтолке не писал, слишком он громоздкий для моих задач был, так что любовь моя к Смолтолку эдакая теоретическая-платоническая :)
А Смолтолк с тех пор мой любимый язык. Вместе с Лиспом. Правда я ничего крупнее самодельного веб-сервера на Смолтолке не писал, слишком он громоздкий для моих задач был, так что любовь моя к Смолтолку эдакая теоретическая-платоническая :)
НЛО прилетело и опубликовало эту надпись здесь
Вы считаете, что нестандартные компоненты добавят приложению usability?
На скриншоте не лог-файлы, а списки договоров. Списки. У вас есть альтернативный способ как их показать?
На скриншоте не лог-файлы, а списки договоров. Списки. У вас есть альтернативный способ как их показать?
НЛО прилетело и опубликовало эту надпись здесь
Объясню. Договора и учётные записи пользователей необходимо искать практически по всем этим параметрам. В том случае, если параметр неуникален — иначе как списком его не покажешь. К примеру, все договора, заключённые вчера. Список полей, которые показываются в этой таблице появился не сразу, а на основе анализа работы сотрудников абонентских отделов. В общем, так удобнее, тем, кто работает с биллингом :)
НЛО прилетело и опубликовало эту надпись здесь
На самом деле ровно так всё и происходит, только вы можете искать не только по имени или по названию, но и по многим другим полям (адрес, тариф и т.д.). В результате поиска вы получите список договоров, удовлетворяющих критерию поиска, а уж потом, пожете каждый из них октрыть для получения полной информации или редактирования.
Да, на нашем сайте в разделе возможности есть и другие скриншоты приложения.
requestbilling.com/images/screenshots/snap_010.jpg
«Халява» возле галочки, что за фамильярность в серьезном продукте? :)
А что означет «Отключать по выработке тарифа» я могу только догадываться :( Очень распостраненная проблема (сами страдаем), такой себе внутренний жаргон провайдера. По собственному опыту знаю, как такие терминологические выходки ставят в тупик оператора, который систему видит первый раз. Усугубляется этот эффект еще и тем, что он до этого использовал другую систему, в которой жаргон был похлеще :)
«Халява» возле галочки, что за фамильярность в серьезном продукте? :)
А что означет «Отключать по выработке тарифа» я могу только догадываться :( Очень распостраненная проблема (сами страдаем), такой себе внутренний жаргон провайдера. По собственному опыту знаю, как такие терминологические выходки ставят в тупик оператора, который систему видит первый раз. Усугубляется этот эффект еще и тем, что он до этого использовал другую систему, в которой жаргон был похлеще :)
Ок, спасибо за замечание, халяву уберём :)
«Отключать по выработке тарифа» это сокращение фразы «Отключать клиента по исчерпанию трафика, входящего в обязательную ежемесячную абонентскую плату тарифного плана». Тоже пережиток прошлого.
«Отключать по выработке тарифа» это сокращение фразы «Отключать клиента по исчерпанию трафика, входящего в обязательную ежемесячную абонентскую плату тарифного плана». Тоже пережиток прошлого.
«Халява» возле галочки, что за фамильярность в серьезном продукте? :)
Что за ханжество на серьёзном хабрахабре?
НЛО прилетело и опубликовало эту надпись здесь
Вы знаете, я тоже недоумеваю по этому поводу и пытаюсь бороться, придумывая более удобные способы навигации, но заказчики (конечные юзеры) упорно просят таблицы с большим количеством полей (аж до абсурда). Меня терзает смутное сомнение, что это побочные эффекты психической травмы от использования Excel и/или 1С, одна тетка так вообще прижимала к стенке с вопросом «где справочники?», как оказалось она имела в виду «жырные» таблицы-списки «как в 1C».
Гуляева Мария Владимировна :)
Вообще надо понимать, что люди продают не столько интерфейс, сколько методу подсчёта и аутсорс обслуживания и допиливания всего этого добра
Дорого не считаете?
Если ориентация на маленьких провайдеров.
К тому же еще язык который никто не знает ( это не перл-си-питон-пхп )
Система неизвестная, не проверенная. Да и АПИ закрытый наверно. А даже если и открытый то из-за смолтолка будет гемора нереально.
Если ориентация на маленьких провайдеров.
К тому же еще язык который никто не знает ( это не перл-си-питон-пхп )
Система неизвестная, не проверенная. Да и АПИ закрытый наверно. А даже если и открытый то из-за смолтолка будет гемора нереально.
Считали, недорого.
Маленькие провайдеры, конечно, хорошо, мы им рады, но лучше если будут средние, это наш размерчик :)
Система проверенная, работает с 2001 года. API предбиллинга открытый, там не Smalltalk, а в самом ядре все операции осуществляются через стандартный интерфейс, там копаться негде.
Маленькие провайдеры, конечно, хорошо, мы им рады, но лучше если будут средние, это наш размерчик :)
Система проверенная, работает с 2001 года. API предбиллинга открытый, там не Smalltalk, а в самом ядре все операции осуществляются через стандартный интерфейс, там копаться негде.
мне кажется средние провайдеры будут выбирать более проверенные биллинги типа bgbilling
Как мне убедить вас, что мы, по крайней мере, не хуже? :)
5 инсталляций биллинга, конечно не цифра, но тем не менее гарантирует достаточную «проверенность».
5 инсталляций биллинга, конечно не цифра, но тем не менее гарантирует достаточную «проверенность».
500 клиентов=50 000р,
при этом модулей практически нет. Другие биллинги и стоят дешевле, и модулей больше ( и история дольше, и комьюнити больше-как у бгбиллинга)
Поэтому сравнивая чисто по функционалу и цене, вы выпадаете. Кстати техподдержка тоже дорогая, как у Billmaster практически.
Поэтому цена должна быть сильно ниже. Или например вы все делаете бесплатно и если система заказчику понравилась, то он тогда платит.
при этом модулей практически нет. Другие биллинги и стоят дешевле, и модулей больше ( и история дольше, и комьюнити больше-как у бгбиллинга)
Поэтому сравнивая чисто по функционалу и цене, вы выпадаете. Кстати техподдержка тоже дорогая, как у Billmaster практически.
Поэтому цена должна быть сильно ниже. Или например вы все делаете бесплатно и если система заказчику понравилась, то он тогда платит.
В эту ориентировочную стоимость, приведённую на сайте, кроме собственно лицензии (как скажем, у бгбиллинга), входит услуги по настройке и установке.
В стоимость техподдержки входят все услуги, связанные с обслуживанием и администрированием. Если вы готовы от этих услуг отказаться — мы предложим вам специальные цены.
> Или например вы все делаете бесплатно и если система заказчику понравилась, то он тогда платит.
Это какая-то странная бизнес-модель.
В стоимость техподдержки входят все услуги, связанные с обслуживанием и администрированием. Если вы готовы от этих услуг отказаться — мы предложим вам специальные цены.
> Или например вы все делаете бесплатно и если система заказчику понравилась, то он тогда платит.
Это какая-то странная бизнес-модель.
НЛО прилетело и опубликовало эту надпись здесь
Да, биллинг это такая странная вещь, там хранится много всяких данных, их можно показывать на одной странице, а можно и на разных вкладках. Знаете, если нас обычно просят что-то переделать — мы всегда идём навстречу.
С удовольствием узнаю название «другого» биллинга.
С удовольствием узнаю название «другого» биллинга.
НЛО прилетело и опубликовало эту надпись здесь
ок, ваше мнение для нас тоже очень важно.
Товарищи, мне после вашего спора стало очень интересно узнать, какой же интерфейс (какой программы) считает идеальным myserg?
Поскольку мой вопрос выше остался неотвеченным, подозреваю, что и вы не дождётесь ответа.
НЛО прилетело и опубликовало эту надпись здесь
>> Почему бы ему не купить другой, авторы которого немного потрудились упростить свои формы?
>> Какой вопрос? Про другой биллинг? Я не занимаюсь этими вопросами но точно знаю, что их много. Не очень понятно почему вы думаете что другой биллинг окажется эталоном совершенства…
Вас там точно один человек пишет под этим ником?
>> Какой вопрос? Про другой биллинг? Я не занимаюсь этими вопросами но точно знаю, что их много. Не очень понятно почему вы думаете что другой биллинг окажется эталоном совершенства…
Вас там точно один человек пишет под этим ником?
НЛО прилетело и опубликовало эту надпись здесь
Простите, а как связаны звонок вам по поводу настройки сети с нашим биллингом?
НЛО прилетело и опубликовало эту надпись здесь
Да, наш проект слишком «тяжёлый» для разграничения доступа в масштабах компании.
Из того, что я видел такого рода — Traffic Inspector почти без вариантов.
Из того, что я видел такого рода — Traffic Inspector почти без вариантов.
НЛО прилетело и опубликовало эту надпись здесь
Мы уже думаем о создании программы масштабов предприятия.
Но думаю это будет не в этом году.
Но думаю это будет не в этом году.
На самом деле можете конечно попробовать поставить TBilling, про который упоминается в начале статьи. Только предупреждаю сразу. Писалось давно. Работает только с pppd на Линуксе. За всеми подробностями мне в почту или в личку.
НЛО прилетело и опубликовало эту надпись здесь
1) Не тяжело сопровождать 2 СУБД в 1м продукте? Если есть уже есть Oracle то зачем MySQL? Зачем лишние звенья плодить?
2) Логика обработки данных вся вынесена или часть реализована средствами Oracle?
3) Поддержка контентного биллинга?
4) DIAMETER?
5) Есть возможность разбора CDR? И если есть, то на сколько развит инструментарий?
6) Можете чуть-чуть поподробнее «предбиллинг» описать таки?
7) RADIUS самописный. Разные «реалмы» умеет? Проксировать с модификацией пакета тоже?
2) Логика обработки данных вся вынесена или часть реализована средствами Oracle?
3) Поддержка контентного биллинга?
4) DIAMETER?
5) Есть возможность разбора CDR? И если есть, то на сколько развит инструментарий?
6) Можете чуть-чуть поподробнее «предбиллинг» описать таки?
7) RADIUS самописный. Разные «реалмы» умеет? Проксировать с модификацией пакета тоже?
1) Ответ простой — fault-tolerance. Исходя из опыта, система становится стабильнее, особенно если предбиллингов несколько. Проблем сделать всё в одной БД нет.
2) Вся логика вынесена. Планировалась легкая портируемость с одной системы БД на другую. Есть в запросах какие-то специфичные оракловые вещи, но сказать, что привязка жёсткая нельзя.
3) Расшифруйте, пожалуйста. Увы, это не общепринятое понятие.
4) Надо?
5) Делаем как бинарные, так и plain-text разборы наиболее распространённых платформ. Если не будет хватать вашего формата — сделаем для вас бесплатно.
6) Можно. Давайте только отдельно статьёй.
7) См. 6, напишем.
2) Вся логика вынесена. Планировалась легкая портируемость с одной системы БД на другую. Есть в запросах какие-то специфичные оракловые вещи, но сказать, что привязка жёсткая нельзя.
3) Расшифруйте, пожалуйста. Увы, это не общепринятое понятие.
4) Надо?
5) Делаем как бинарные, так и plain-text разборы наиболее распространённых платформ. Если не будет хватать вашего формата — сделаем для вас бесплатно.
6) Можно. Давайте только отдельно статьёй.
7) См. 6, напишем.
1-2) Зато высокие накладные расходы в цепочке mysql-app-oracle. Нагрузка чуть чуть вырастет и начнутся чудеса. И код раздувается. Как вариант на вскидку. Что мешает взять oracle xe для предбиллинга, его 4GB табличного пространства с головой хватит. И то же табличное пространство можно примонтировать к «большому» инстансу. Или вообще отказать от Oracle (существенно снизить цену продукта), все равно не используете его возможности вынеся логику вне его, ваши объемы данных вполне MySQL сможет обработать.
В общем, настораживает меня ваша архитектура.
3) Самая представительная железка Cisco CSG. Направление перспективное. Особенно для Wi-Fi сетей. И вполне общепринятое понятие.
4) Ну как бы диаметр — эволюция радиуса, и возможностей побольше и попроще, мне по крайней мере. Жаль железки го плохо пока поддерживают.
5) Т.е. возможности настроить разбор самостоятельно, без привлечения разработки нет?
6) Пишите, очень мне интересно будет почитать.
В общем, настораживает меня ваша архитектура.
3) Самая представительная железка Cisco CSG. Направление перспективное. Особенно для Wi-Fi сетей. И вполне общепринятое понятие.
4) Ну как бы диаметр — эволюция радиуса, и возможностей побольше и попроще, мне по крайней мере. Жаль железки го плохо пока поддерживают.
5) Т.е. возможности настроить разбор самостоятельно, без привлечения разработки нет?
6) Пишите, очень мне интересно будет почитать.
Всё замечательно работает на 20 тыс. vpn клиентах на железе 5-летней давности. Можно взять и Postgres, и Berkley DB, но я вам уже написал, для чего это было сделано. Про портируемость уже тоже писал.
Cisco CSG пока не поддерживаем.
Что такое diameter я знаю. Я спрашивал, зачем поддерживать ещё и его.
Мы настраиваем все ваши форматы CDR на этапе инсталляции.
Cisco CSG пока не поддерживаем.
Что такое diameter я знаю. Я спрашивал, зачем поддерживать ещё и его.
Мы настраиваем все ваши форматы CDR на этапе инсталляции.
Забыл.
8) Опишите систему отчетности.
9) Руководство пользователя — хлам. Перепишите.
8) Опишите систему отчетности.
9) Руководство пользователя — хлам. Перепишите.
8) По отчётности сейчас всё достаточно просто. Есть перечень стандартных отчетов (ежемесячные, ежедневные и т.д.), которые мы предлагаем заказчику и из которых тот выбирает или предлагает собственные. Отчёты выгружаются, как правило в Excel или dbf (а в принципе в любую odbc-compatible базу данных). Есть модуль сопряжения для 1С для импорта начислений из биллинга. Есть внутренняя система отчетов, позволяющяя формировать счета, счета-фактуры, акты выполненных работ непосредственно из биллинга.
9) Знаем, извините. Пока оно deep under construction.
9) Знаем, извините. Пока оно deep under construction.
Прочитал пост, посетил сайт, скачал документацию. Мнение: уровень все-таки еще ох как не дотягивает до серьезных продуктов. 22 страницы документации — это смешно. :-) Где API можно посмотреть? И вообще — хочется больше данных и информации. Выше уже вопросы самые очевидные написали…
Модель лицензирования и ценообразования понятна — предоставить клиенту сервис и чтобы он ни о чем не парился, а только башлял каждый месяц. А тот кто предоставляет сервис постарается все один раз настроить и потом спокойно собирать деньги. :-) Однако, я бы не сказал, что она оптимальна с точки зрения операторов связи. :-) У оператора связи всегда есть свой/свои админ/админы, а у оператора среднего размера — даже зачастую программист. ;-) Платить кому-то ежемесячно за сопровождение совершенно не интересно, учитывая, что все равно должен быть человек, который худо-бедно знает и понимает биллинг, чтобы грамотно ставить сопровождающим задачи и грамотно их контролировать. Ну, а раз он уже худо-бедно понимает, то все приходят к тому, чтобы он его и ковырял. :-) Это не умозаключения, а реальная жизнь, проявления которой я видел неоднократно. И именно в этой связи наиболее оптимальна все-таки схема лицензирования и вообще характеристики BGBilling'а: достаточно высокая плата за вход (но и не заоблачная — в 100 штук плюс-минус укладывается все-все-все), бесплатные обновления после покупки и максимально открытая документация. Хочешь новый функционал — плати, но хотя бы понятно, за что платишь. Не хочешь платить и сам весь из себя умный — читай доки, ковыряй API и сам пиши примочки, благо все на Яве, а ее сейчас только ленивый не знает.
В общем, я бы будучи руководителем со всем этим хозяйством связываться не стал. Зачем себя привязывать за свои же деньги к поставщику, который будет продолжать тебя «доить» и с продуктом которого будут проблемы в поддержке (попробуйте найти специалистов по Smalltalk)? Я ни в коем случае не умаляю возможных достоинства выбранного языка и качеств продукта, но не вполне уверен в том, что это то, что нужно массовому рынку.
Модель лицензирования и ценообразования понятна — предоставить клиенту сервис и чтобы он ни о чем не парился, а только башлял каждый месяц. А тот кто предоставляет сервис постарается все один раз настроить и потом спокойно собирать деньги. :-) Однако, я бы не сказал, что она оптимальна с точки зрения операторов связи. :-) У оператора связи всегда есть свой/свои админ/админы, а у оператора среднего размера — даже зачастую программист. ;-) Платить кому-то ежемесячно за сопровождение совершенно не интересно, учитывая, что все равно должен быть человек, который худо-бедно знает и понимает биллинг, чтобы грамотно ставить сопровождающим задачи и грамотно их контролировать. Ну, а раз он уже худо-бедно понимает, то все приходят к тому, чтобы он его и ковырял. :-) Это не умозаключения, а реальная жизнь, проявления которой я видел неоднократно. И именно в этой связи наиболее оптимальна все-таки схема лицензирования и вообще характеристики BGBilling'а: достаточно высокая плата за вход (но и не заоблачная — в 100 штук плюс-минус укладывается все-все-все), бесплатные обновления после покупки и максимально открытая документация. Хочешь новый функционал — плати, но хотя бы понятно, за что платишь. Не хочешь платить и сам весь из себя умный — читай доки, ковыряй API и сам пиши примочки, благо все на Яве, а ее сейчас только ленивый не знает.
В общем, я бы будучи руководителем со всем этим хозяйством связываться не стал. Зачем себя привязывать за свои же деньги к поставщику, который будет продолжать тебя «доить» и с продуктом которого будут проблемы в поддержке (попробуйте найти специалистов по Smalltalk)? Я ни в коем случае не умаляю возможных достоинства выбранного языка и качеств продукта, но не вполне уверен в том, что это то, что нужно массовому рынку.
Угу, верно написано, я практически тоже самое писал вверху.
По документации — habrahabr.ru/blogs/startup/70017/#comment_1999035
На вопросы выше попытался чуть подробнее ответить.
Ну у нас тоже есть партнеры-операторы связи — они тоже ни о чём не парятся. Мне кажется, многие вещи здесь вы говорите как админ, а не как руководитель предприятия. Понимаете, ковырять надо там, где шаг влево-шаг вправо расстрел. У нас ковырять ничего не надо, всё уже сделано, или будет сделано при лучшем соотношении цена/качество.
Мы не хотим быть еще одним бгбиллингом, ланбиллингом, нетапом. Когда клиент заплатил деньги, а потом имеет секс с программой за собственные деньги. Ваш биллинг — наша головная проблема. И у нас не возникнет проблем с пониманием требований заказчика. Как, собственно, и заказчика не будет волновать, на чём это написано — на Smalltalk или бейсике.
На вопросы выше попытался чуть подробнее ответить.
Ну у нас тоже есть партнеры-операторы связи — они тоже ни о чём не парятся. Мне кажется, многие вещи здесь вы говорите как админ, а не как руководитель предприятия. Понимаете, ковырять надо там, где шаг влево-шаг вправо расстрел. У нас ковырять ничего не надо, всё уже сделано, или будет сделано при лучшем соотношении цена/качество.
Мы не хотим быть еще одним бгбиллингом, ланбиллингом, нетапом. Когда клиент заплатил деньги, а потом имеет секс с программой за собственные деньги. Ваш биллинг — наша головная проблема. И у нас не возникнет проблем с пониманием требований заказчика. Как, собственно, и заказчика не будет волновать, на чём это написано — на Smalltalk или бейсике.
Понимаете, руководителю предприятия обычно глубоко по фиг на такие детали, как всякие внутренние заморочки с биллингом — просто нужно, чтобы все работало. Админ же — это просто исполнитель — ему что сказали, то он и сделал. :-) А принимать решения и вникать будет тех.директор (что, кстати, не исключает объединения его в одном лице с админом или руководителем) и ему все упомянутые мной и другими комментаторами вещи вполне имеют значение.
Опять же, аутсорсинг у нас в стране развит слабо и руководителю любого уровня будет не вполне понятно, зачем он должен платить деньги вам, когда у него в штате есть -дцать админов/программеров и обслуживание биллинга входит в их компетенцию. При этом работая с вами процесс явно усложняется: одно дело вправить мозги и наорать на своего сотрудника, а другое — взаимодействовать и коммуницировать с посторонней организацией, от которой все время надо всего добиваться… Короче, административные/организационные/транзакционные издержки больше и чтобы это понять — не нужно быть семи пядей во лбу.
Такого, чтобы ничего не надо было ковырять — не бывает. Биллинг — это, к сожалению, не унифицированный продукт и приходится либо изначально раздувать его функционал, либо делать доступным тот же API, чтобы заказчику было иметь секс с биллингом максимально просто и комфортно. :-) Т.е. в теории у вас все, конечно, верно — насчет разделения труда и ответственности и все такое, — но практика немного иная получается. Такая, что одна половина операторов связи пишет биллинги сама (совершенно не круто и нетехнологично, а как им удобнее и как им нравится), а другая, которая все-таки использует покупные решения (все-таки их существенно быстрее разворачивать и меньше проблем с сертификацией), перманентно жлобится на тех.поддержку и оплату доп.услуг производителя и хочет как раз всякие API. Почитайте форум НетАпа — какая там эпопея длиной в несколько лет был насчет доступа к закрытому протоколу URFA по общению с ядром. И как народ сейчас счастлив тому, что хоть что-то получили, так что могут теперь — пусть косо, криво и не все, что хочется, но все-таки — самим чего-то дописывать и иметь секс с биллингом, что их совершенно не смущает и не коробит. :-) И про БГБиллинг тоже почитайте — как народ радуется изначально открытому API и какое удовольствие от секса с биллингом получает. :-)
Короче, тезис всего моего флуда очень прост: отечественному массовому потребителю АСР не нужны продукты под ключ и он не хочет отдавать кому-то обслуживание биллинга на аутсорсинг (кстати, пришел в голову еще один аргумент за это — ведь в биллингах зачастую куча «черной» информации, которую боятся слить на сторону). Подчеркиваю — массовому потребителю. Вы вполне можете иметь свою нишу — несколько клиентов, с которыми вы вплотную работаете, которых обслуживаете и для которых вы по сути — если говорить прямо — и пишите свой биллинг. В этом нет ничего плохого, просто надо это осознавать. И если вы хотите идти на массовый рынок, то что-то менять и о многом дополнительно думать.
Все вышесказанное, конечно же, исключительно мое личное мнение, не претендующее на объективность. :-) Но мне кажется, что я не так уж и неправ. :-)
Опять же, аутсорсинг у нас в стране развит слабо и руководителю любого уровня будет не вполне понятно, зачем он должен платить деньги вам, когда у него в штате есть -дцать админов/программеров и обслуживание биллинга входит в их компетенцию. При этом работая с вами процесс явно усложняется: одно дело вправить мозги и наорать на своего сотрудника, а другое — взаимодействовать и коммуницировать с посторонней организацией, от которой все время надо всего добиваться… Короче, административные/организационные/транзакционные издержки больше и чтобы это понять — не нужно быть семи пядей во лбу.
Такого, чтобы ничего не надо было ковырять — не бывает. Биллинг — это, к сожалению, не унифицированный продукт и приходится либо изначально раздувать его функционал, либо делать доступным тот же API, чтобы заказчику было иметь секс с биллингом максимально просто и комфортно. :-) Т.е. в теории у вас все, конечно, верно — насчет разделения труда и ответственности и все такое, — но практика немного иная получается. Такая, что одна половина операторов связи пишет биллинги сама (совершенно не круто и нетехнологично, а как им удобнее и как им нравится), а другая, которая все-таки использует покупные решения (все-таки их существенно быстрее разворачивать и меньше проблем с сертификацией), перманентно жлобится на тех.поддержку и оплату доп.услуг производителя и хочет как раз всякие API. Почитайте форум НетАпа — какая там эпопея длиной в несколько лет был насчет доступа к закрытому протоколу URFA по общению с ядром. И как народ сейчас счастлив тому, что хоть что-то получили, так что могут теперь — пусть косо, криво и не все, что хочется, но все-таки — самим чего-то дописывать и иметь секс с биллингом, что их совершенно не смущает и не коробит. :-) И про БГБиллинг тоже почитайте — как народ радуется изначально открытому API и какое удовольствие от секса с биллингом получает. :-)
Короче, тезис всего моего флуда очень прост: отечественному массовому потребителю АСР не нужны продукты под ключ и он не хочет отдавать кому-то обслуживание биллинга на аутсорсинг (кстати, пришел в голову еще один аргумент за это — ведь в биллингах зачастую куча «черной» информации, которую боятся слить на сторону). Подчеркиваю — массовому потребителю. Вы вполне можете иметь свою нишу — несколько клиентов, с которыми вы вплотную работаете, которых обслуживаете и для которых вы по сути — если говорить прямо — и пишите свой биллинг. В этом нет ничего плохого, просто надо это осознавать. И если вы хотите идти на массовый рынок, то что-то менять и о многом дополнительно думать.
Все вышесказанное, конечно же, исключительно мое личное мнение, не претендующее на объективность. :-) Но мне кажется, что я не так уж и неправ. :-)
Вы правы на 100% в случае, если разработчик неисполнителен и безответственен. С другой стороны аутсорсинг — это действительно очень удобно, например мы сами отдали бухучет аутсорсерам.
Во-первых, в других случаях я тоже хотя бы отчасти прав. ;-) Во-вторых, ВСЕ разработчики рано или поздно становятся неисполнительны и безответственны — и вы тоже, конечно. :-) Это не наезд, упаси Боже, и не принижение ваших достоинств. Это, скорее, ода малому бизнесу, который из-за небольшого количества клиентов может обеспечить индивидуальный подход и нормальное качество. Поверьте мне — как только у вас станет такое же количество клиентов (а не пять человек) и сопутствующих организационных проблем, как у того же НетАпа — у вас тут же возникнут и все соответствующие «косяки». И придется либо снижать качество, либо повышать цену, либо рассчитывать на то, что админы сами доковыряют. Из-за спефицики рынка снизить издержки за счет унификации у вас не получится — можете даже и не спорить. Соответственно, каждый разработчик идет своим путем — одним из вышеуказанных. Из-за того, что менеджмент у нас в стране большей частью — полная лажа, — все у всех сводится к примерно одинаковой схеме: предоставление унифицированного продукта с дешевой тормозной и некачественной тех.поддержкой и возможностью за отдельные большие деньги доразработать заказчику что-нибудь индивидуальное и оказать индивидуальную качественную тех.поддержку. BGBilling сделал шаг вперед — он полностью отказался от дешевой разновидности тех.поддержки, полностью перекинув эти силы на нормальную документацию и поддержку на форуме (что по сути совмещается с бета-тестингом, а значит убиваются два зайца сразу). В итоге на них не ругаются за раздолбайство, ибо его по факту нет — услуга соответствующего уровня и цены отсутствует и люди либо доковыривают себе что-то сами (благо есть такая возможность), либо таки платят деньги и получают все в ажуре. Суть моего спича лишь в том, чтобы вы определились, какой рынок вам нужен и как вы хотите себя на нем вести. Если рынок узкий — все в порядке, не парьтесь, а если хотите «поработить всех», то лучше сразу подумайте и идите в правильном направлении, чтобы не стать еще одним тем же НетАпом.
ps: Отдача бух.учета на аутсорс не считается — из-за своей банальности, очевидности и т.п. ;-) Вот будет у вас много клиентов — попробуйте тех.поддержку 1-го level'а на аутсорс отдать. :-) Дык нет же — предпочтете пару студентов посадить на телефон. :-)
ps: Отдача бух.учета на аутсорс не считается — из-за своей банальности, очевидности и т.п. ;-) Вот будет у вас много клиентов — попробуйте тех.поддержку 1-го level'а на аутсорс отдать. :-) Дык нет же — предпочтете пару студентов посадить на телефон. :-)
По API. Именно у сервера биллинга сейчас так такого api нет, НО smalltalk — динамический язык, работает внутри своей виртуальной машины, следовательно ему можно на лету подбрасывать код для выполнения. Следовательно имея загруженный биллинг (необходимые объекты загружены из базы) мы можем отдавать почти любую информацию в всех доступных форматах.
На самом деле, нас просто ещё никто не спрашивал про API именно для сервера, поэтому и не заморачивались на эту тему.
На самом деле, нас просто ещё никто не спрашивал про API именно для сервера, поэтому и не заморачивались на эту тему.
Я о том и пишу — вы с другой нишей работаете… Если бы API был никому не нужен — его бы никто не предлагал, а с НетАпом так бы за URFA не боролись…
Может клиенты от безысходности API запросили, т.к. функционала не хватало, а дождаться от разработчиков реализации недостающих возможностей нереально?
Угу, так и есть. Но что это меняет в итоге? :-) Речь же и идет о выборе: либо платить деньги и пытаться чего-то добиться от разработчика, что в условиях отвратительной российской сферы услуг (не в частности, а в среднем), чревато геморроем, либо же плюнуть на всех, засучить руками и самому сделать нужный себе функционал за несколько дней. Отечественные операторы выбирают второй путь по мере возможности. А то как помню, НетАп за реализацию минимальной индивидуальной фичи в конкретном релизе — без обязательства ее поддержки в будущих — берет что-то около 30 штук и не дает точных сроков по реализации — т.е. платишь и ждешь, ждешь, ждешь… Потом месяц пользуешься, выходит новый релиз, в котором твоей фичи нет и ты снова платишь, чтобы ее туда внесли (таки ведь новый релиз фиксит кучу багов! И не обновляться на него — себе же дороже!), и снова ждешь, ждешь, ждешь… У меня приятели в одном провайдере после подобных приключений плюнули и полностью переписали весь фронтенд от того же UTM5. Т.е. у них крутится ядро, собирает статистику и складывает в базу. А весь админский и пользовательский интерфейс написан самопалом на PHP и тупо читает из базы чего там наскладывало и насчитало ядро. Ребята довольны как слоны и в полном восторге, что им не нужно работать с Явовскими УТМными фронтендами… :-)
Понимаете, тем наш биллинг и отличается от UTM. На нём действительно работают, as is, а не покупают для сертификата и не подтыкивают костылями. Для нас главное не количество продаж, а полноценное развитие каждой инсталляции.
При чем тут костыли? Речь идет именно о реализации необходимого конкретному клиенту функционала. Одним надо платежи через Webmoney принимать, вторым — через Я.Д., третьим — через Киви, четвертым — все это вместе взятое плюс кредитки через КиберПлат, а пятые сидят на Дальнем Востоке и им кровь из носу нужно воткнуть ту платежную систему, которая натыкала автоматов именно у них в районе и имеет свои собственные интерфейсы. А вот я еще люблю абонентам по SMS рассылать уведомления о том, когда у них деньги кончаются — разнообразных SMS-биллингов вообще море и с кем я захочу работать не знаете не только вы, но и я сам. ;-) Или вот еще типичная задача — раз уж все равно провода везде висят, очень хочется поставить на крыше outdoor точку доступа и предоставлять wifi по карточкам. Или же в какой-нибудь кафешке договориться с владельцами и заниматься тем же самым…
И так далее, и тому подобное. В сфере банального районного провайдинга огромное количество всяких разных возможностей, услуг и т.п. — я уж не говорю о более серьезных уровнях. Учесть их всех изначально — невозможно. Особенно, если вы небольшая организация. Поэтому API — это единственный адекватный путь расширения.
Но, повторяюсь, если вы не нацелены на широкий рынок — то вам должно быть по фиг. :-)
И так далее, и тому подобное. В сфере банального районного провайдинга огромное количество всяких разных возможностей, услуг и т.п. — я уж не говорю о более серьезных уровнях. Учесть их всех изначально — невозможно. Особенно, если вы небольшая организация. Поэтому API — это единственный адекватный путь расширения.
Но, повторяюсь, если вы не нацелены на широкий рынок — то вам должно быть по фиг. :-)
Да, ещё: мы пользуемся Continuous Integration, релизы бывают у нас не реже трех раз в неделю. Иногда чаще, до нескольких в день. И каждый раз обновляются серверные и клиентские части приложения.
Извините, но не могу оценить это положительно. :-) Это получается эксплуатирование клиентов в качестве бета-тестеров. Я лично вообще против частых релизов биллинга. Т.е. бета-релизы быть должны — кто хочет тот пусть и тестит. Но каждый раз выпускать новую версию и тут же всех клиентов на нее переводить — это жесть…
Для бизнес-логики у нас пишутся unit-тесты, изменения в интерфейсе релизим после внутреннего тестирования. Чем раньше будет получен отклик на внесённые изменения, тем меньше будет негативный эффект. Естественно, в первую очередь релизится биллинг в той компании, для которой предназначены эти изменения.
Без API биллинг неполноценен. Обслуживание биллинга без API — редкое извращение.
А почему Dolphin, а не VisualWorks? Только из-за лицензии, или есть какие-то другие причины?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
АСР «Реквест-Биллинг»