forum.bitel.ru
http://forum.bitel.ru/

bsh — to be, or not to be
http://forum.bitel.ru/viewtopic.php?f=1&t=7705
Страница 1 из 2

Автор:  dimOn [ 11 фев 2013, 16:24 ]
Заголовок сообщения:  bsh — to be, or not to be

В одной из следующих версий планируется полностью убрать поддержку bsh-скриптов, оставить только динамический код. Слегка придётся потратиться на переписывание скриптов итд, но в целом оно того стоит. Дин.код более надёжный, удобный, прогрессивный, производительный, нативный, некостыльный. А так получится быстрее согнать людей на него. Что вы об этом думаете?

Автор:  skyb [ 11 фев 2013, 18:45 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

а все события есть? а поможите портировать несколько скриптов? и предлагаю сделать это в определенной версии, а не при переходе с версии на версию

Автор:  dimOn [ 11 фев 2013, 18:48 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

причём тут события? сейчас на все события можно дин.код повесить, как и bsh-скрипты

Автор:  snark [ 11 фев 2013, 19:03 ]
Заголовок сообщения: 

Уход в нативную яву понятен - быстрее, выше, сльнее, но ... НО! Скриптинг на нативной яве значительно (очень!) повышает порог входа, т.е. не программисту будет значительно сложнее, т.к. для обычного админа это запросто может выглядеть как переход с написания скриптиков на каком нить шелле/похапе и тут же ему предлагают писать то же самое на С/С++.
Наличие скриптинига в БГБ является одной из его уникальных фишек и я всем рекламирую БГБ именно как биллинг где можно написать нечто и это не будет костылем, а будет частью системы. Как бы не получилось так, что в погоне за лучшим отпугнете потенциальных покупателей, т.к. эта тема, в общем то, больше о них, т.к. нам то уже деваться некуда - надо на яве - будем писать на яве.

Слоган: Купив БГБ станешь эльфом ява кодером 80 уровня.

Автор:  dimOn [ 11 фев 2013, 19:11 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

Цитата:
Скриптинг на нативной яве значительно (очень!) повышает порог входа
имхо, спорно. порог входа как раз очень сравним. по сути код мало отличается, если писать на bsh правильно.

Автор:  skyb [ 11 фев 2013, 19:13 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

dimOn писал(а):
причём тут события?

при том что раньше не все события были
dimOn писал(а):
сейчас на все события можно дин.код повесить, как и bsh-скрипты

вот и ответ

Автор:  max [ 11 фев 2013, 20:16 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

я тоже против, ну не знаю я яву, а на перле могу написать что нужно.

Автор:  dimOn [ 11 фев 2013, 20:25 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

и чо, клёво на перле скрипты пишутся в bgbilling? :lupa:

Автор:  stark [ 11 фев 2013, 20:33 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

skyb писал(а):
и предлагаю сделать это в определенной версии, а не при переходе с версии на версию


эта фраза поставила меня в ступор. Здесь имеется ввиду что перейти в середине определенной версии ? ну давайте в 5.2 следующим апдейтом..или как ?

Автор:  snark [ 11 фев 2013, 21:32 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

Чтобы было сразу ясно - мне совершенно все равно на чем будут писаться скрипты под БГБ - что надо будет, то и выучим (благодаря БГБ я хоть как-то начал шарить в яве).
Вопрос больше в новичках - их может отпугнуть одна только фраза "программирование на ява", а мне не хочется, чтобы нашего полку не прибывало только из за этого.

Автор:  Phricker [ 11 фев 2013, 21:45 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

snark писал(а):
Чтобы было сразу ясно - мне совершенно все равно на чем будут писаться скрипты под БГБ - что надо будет, то и выучим (благодаря БГБ я хоть как-то начал шарить в яве).

+1.

А для новичков все таки bsh как-то по проще. я так вот до сих пор не пойму что такое дин.код и с чем его едят. и правила его написания не понимаю.
а на bsh можно по примерам из вики научиться.

Автор:  barguzin2 [ 11 фев 2013, 22:47 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

Уход от BSH к дин.коду поддерживаю. Сам я с БГ, и с джава следом не сильно давно знаком. До этого как и большинство php/perl. Что хочу сказать как относительный новичок - да как-то не очень на BSH то писать после скриптовых (особенно в простом редакторе типа Notepad+ или напрямую в редакторе биллинга), всё равно тут тебе сразу классы и прочее и юзаешь в основном API биллинга, который есть классы чистой Java.

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

Да, BSH прощает объявление переменных(тут спорный плюс) и типизицию, да где-то что-то можно недописать, НО! когда я открыл для себя Эклипс - тут чистая джава даже после perl/php стала прелестью: вот тебе все подсказочки/ошибочки, вот тебе все методы, вот тебе все импорты, вот тебе все остальные прелести. Потом всё это копипастишь, компилишь и готово. Красота.

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

По ходу вопрос - какими средствами писать на BSH чтобы его потом можно было также скопипастить просто. Эклипс или аналогичные IDE умеют ?

В общем, цель правильная. У вас же на сайте четко написано - Эволюцию не остановить. И если человек имеет понятие что такое программирование - то и на джаве код напишет если надо, а если не имеет - то будь там хоть bsh, хоть perl/php - ничего не выйдет.

Моё +1. Мне не всё равно. Only Pure Java :)

Автор:  barguzin2 [ 11 фев 2013, 23:03 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

Phricker писал(а):
А для новичков все таки bsh как-то по проще. я так вот до сих пор не пойму что такое дин.код и с чем его едят. и правила его написания не понимаю.
а на bsh можно по примерам из вики научиться.


Да ладно уже новичком прикидываться.
Так если что непонятно - спрашивай, желательно на конкретном примере. Дин.код - это тот же скрипт предобработки/глобальный скрипт, тока не на bsh, а чистый Java Class, скелет которого создается при добавлении обработчика события. Внутрь пишешь почти тот же код, что и на bsh.

Думаю стоит написать пример в Wiki переделывания скрипта поведения и глобального скрипта в дин.код. Тогда много вопросов сразу отпадет. Может даже займусь, если время будет :)

Автор:  snark [ 12 фев 2013, 03:35 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

Ар-р-р ... Да все кто тут шарахается не будет испытывать проблем с дин кодом и прекрсно понимают, что ява - это наше усе. Тут речь больше о новичках, чтобы их не спугнуть. Лично я не хочу, чтобы кто-то от БГБ отказался только потому что "ой вей, там таки чистая ява!".

Как донести мысль: я хочу, чтобы БГБ использовало бОльше операторов?

Автор:  skyb [ 12 фев 2013, 05:28 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

stark писал(а):
skyb писал(а):
и предлагаю сделать это в определенной версии, а не при переходе с версии на версию

эта фраза поставила меня в ступор. Здесь имеется ввиду что перейти в середине определенной версии ? ну давайте в 5.2 следующим апдейтом..или как ?

Я думаю всетаки с 5.3 и после обновления все bsh объявить в деприкейты
barguzin2 писал(а):
Думаю стоит написать пример в Wiki переделывания скрипта поведения и глобального скрипта в дин.код. Тогда много вопросов сразу отпадет. Может даже займусь, если время будет :)

Дык при создании класса там уже есть вход, можно уже там писать используя эклипс. Или я не про то думаю?

Автор:  skyb [ 12 фев 2013, 07:09 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

Кстати, а как с табличными отчетами будет?

Автор:  barguzin2 [ 12 фев 2013, 09:12 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

snark, да новичкам и bsh (по своему опыту скажу) после perl/php/bash - диковиной кажется. Еще раз повторюсь - хоть это дин.код, хоть bsh, API есть API, его применение ничем не отличается и без него никуда. А по большому счету все сводится к тому, что нужно объявить переменные и немного последить за типизацией, а саму джаву и в случае bsh все равно придётся подучить.

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

С табличными отчетами думаю будет вот как - в report.rep.xml указывается класс дин.кода, в котором также будет фигурировать метод fillReport.

Автор:  dimOn [ 12 фев 2013, 11:37 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

barguzin2 писал(а):

По ходу вопрос - какими средствами писать на BSH чтобы его потом можно было также скопипастить просто. Эклипс или аналогичные IDE умеют ?

Я пишу в эклипсе так же как и дин.код. С точностью до варнингов валидный bsh-код является валидным java-кодом. Именно потому мне байки про разный порог вхождения совершенно непонятны.

Автор:  barguzin2 [ 12 фев 2013, 12:02 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

Да здесь получается больше вопрос переноса биншел скриптов в дин.код, да и то это не большая проблема если API опять не поменяется. А если поменяется - то тут прямо судьба всё в дин.код сразу перегнать.

Автор:  aiwbend [ 12 фев 2013, 13:06 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

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

Автор:  max [ 12 фев 2013, 22:30 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

dimOn писал(а):
и чо, клёво на перле скрипты пишутся в bgbilling? :lupa:

а я не пишу скрипты в бгп, я их пишу как обвязку.

Автор:  max [ 12 фев 2013, 22:32 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

Phricker писал(а):
А для новичков все таки bsh как-то по проще. я так вот до сих пор не пойму что такое дин.код и с чем его едят. и правила его написания не понимаю.
а на bsh можно по примерам из вики научиться.

+100

Автор:  aardvark [ 13 фев 2013, 16:08 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

Я полностью за. Наличие bsh, с отсутствием генериков, заставляет меня держать в git версию на bsh и версию с генериками на Java. И вобще не даёт полностью уйти от bsh в сторону более чистой явы и правильной оптимизации. Тормоз это технологический.

Автор:  dimOn [ 13 фев 2013, 16:21 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

так сейчас всё что можно писать на bsh можно писать и на дин.коде :umnik:

Автор:  skyb [ 13 фев 2013, 17:24 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

dimOn писал(а):
так сейчас всё что можно писать на bsh можно писать и на дин.коде :umnik:

а автоподстановка пользователей как?

Автор:  dimOn [ 13 фев 2013, 17:44 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

что, простите?

Автор:  Akhmat [ 13 фев 2013, 18:23 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

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

Автор:  skyb [ 13 фев 2013, 18:44 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

dimOn писал(а):
что, простите?

http://wiki.bgbilling.ru/index.php/%D0% ... 0%B3%D0%B0

Автор:  barguzin2 [ 13 фев 2013, 19:10 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

dimOn писал(а):
так сейчас всё что можно писать на bsh можно писать и на дин.коде :umnik:

Чой-то не вижу где дин.код для предобработки радиус запросов VoIP :lupa: , а это достаточно критичное к производительности место. Это можно как-то быстренько впилить? Чтобы в конфиге НАСа указываешь типа packet.preprocess.class=ru.dyn.code и пишешь класс предобработки. Конечно, выбор класса дин.кода из списка, добавление его тут же в клиенте это всё удобно, но пока хотя бы так. Очень хочется.

Или в связи с разработкой нового модуля на voiceip наложили крест ?

И добавление к теме. О чём диспут то, читаем http://bgbilling.ru/v5.2/doc/ch02s01.html - разница очевидна. BSH искоренить, тему закрыть :)

Автор:  zavndw [ 14 фев 2013, 03:47 ]
Заголовок сообщения:  Re: bsh — to be, or not to be

я за переход со следующей версии т.е это с 5.3

Страница 1 из 2 Часовой пояс: UTC + 5 часов [ Летнее время ]
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/