Помогите выбрать биллинг

[dead 93]

Никто не спорит, что тесты это хорошо. Проблема в том, что написанием топовых биллингов, к коим я отношу и свой (старой версии более тысячи работающих инсталяций (каюсь, все знают, что там есть шпионская штука, в новом нет - все исходники открыты)) как правило занимается один человек на биллинг. Идет куча запросов на наращивание функционала. И тут стоит выбор - либо написать тесты либо фичу. А поскольку мы живем в реальности, то кроме правильных подходов к написанию, на нас давит масса всего - маркетинг, обязательства и т.д и т.п. на которые совершенно правильно, и я с тобой согласен, ты скажешь "это ваши проблемы". Однако, повторюсь, топовые биллинги пишутся одиночками. Так что придется смириться с этим.

 

Лично в моем проекте связность скриптов довольна слабая (в отличие от N49/N50), т.е. изменяя скрипт я в 99,9% не затрону работу других. Это подтверждается крайне малых количеством (найденных) багов. Да, у меня есть пару тестов на основные модули, в частности на работу с БД. Все остальные фичи я беру и тупо проверяю, моделирую разные ситуации. Может у меня мало опыта в тестах, но смоделировать вручную (скриптами)  сложную ситуацию (например дисконнект бд в момент работы скрипта) мне проще вручную.

 

А вообще, довольно много людей мне говорили "все неправильно, я напишу свое". Клянусь, в 100% случаев у них так и не доходило до хоть сколько-то вменяемо работающей программы. Биллингописание - это многолетняя работа через кучу проб и ошибок, которые остаются в коде, и никак их не выкинуть ибо куча лентяев не хотят обновляться либо у них куча своих фич заточены под когда-то сделанные разработчиком костыли

[ttttt 195]

И тут стоит выбор - либо написать тесты либо фичу.

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

 

но смоделировать вручную (скриптами)  сложную ситуацию (например дисконнект бд в момент работы скрипта) мне проще вручную.

Да не сложно, mock object вместо реального объекта бд и все тестируется.

У вас же перл вроде? В перл еще проще, одну функцию подменил и моделируешь что хочешь: *MyPkg::method = sub { ... };

[nightfly 1 222]

Да-да господин разработчик несуществующих продуктов - продолжайте пожалуйста.

Очень интересно.

[dead 93]

 У меня есть друг. Хороший программист. Но он утопает в своем "деланьи правильно". Я ему как-то сказал: вот, что ты в своей жизни сделал такого, о чем тебя смогут вспомнить? Лучший оптимизатор sql запросов?

 

Ты понимаешь, что сущностей у продукта настолько дофига, что нельзя взять и все разложить по-полочкам. Тесты - это только одна из тысячи вещей, причем далеко не первостепенная. Раньше все писали без тестов, а надежность кода была выше. Чтобы покрыть тестами продукт, нужно хотя бы ТЗ. А оно меняется прямо сегодня. Вчера всем нужна была эта фича, а сегодня ее использование уже считается плохим тоном. А она осталось в коде и на нее написан тест (потрачено время). Это у тебя так просто - есть проблема ->  есть решение. Ты понимаешь, что идеологии создания продукта могут быть разными? Я, например, не включу в проект вещь, в которой я разобрался меньше чем на 90%. Просто не доверяю никому. И это имеет свои плоды - надежность кода - это чем я могу спокойно гордиться. Поэтому что бы включить чьи-нибудь тесты, мне нужно потратить дофига времени - почитать о них отзывы, посмотреть их код, опробовать на другом проекте, выждать время.  Это все время. А у меня еще есть основная работа. А есть еще хобби. И так у каждого из нас. Биллинг не приносит достаточно денег чтобы забыть о дополнительном заработке. Приходится лавировать. Главное - конечный продукт людям нравится и они на нем зарабатывают деньги. Поэтому, мы имеем право писать код так как пишем, потому что людям от этого польза. Поэтому критика в таком резком тоне - неуместна. Как совет - вполне

[ttttt 195]

Ты понимаешь, что сущностей у продукта настолько дофига, что нельзя взять и все разложить по-полочкам. Тесты - это только одна из тысячи вещей, причем далеко не первостепенная. Раньше все писали без тестов, а надежность кода была выше. Чтобы покрыть тестами продукт, нужно хотя бы ТЗ. А оно меняется прямо сегодня. Вчера всем нужна была эта фича, а сегодня ее использование уже считается плохим тоном.

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

 

И вы так говорите, как будто тесты писать это долго. Вы написали функцию - вы же ее как-то проверяете? Какая разница, написать эту проверку в юнит тесте или проверить ручками? Как показывает практика - ручками даже один раз тестировать дольше, чем написать тест. Исключение только если вы никогда в жизни не писали тесты и тесты для вас что-то "новое". Ну тогда добро пожаловать в мир программирования. И не нужне же сразу все-все-все проверять, только минимум, потом будут баги, добавите больше тестов.

 

Но за код без тестов должно быть стыдно. Можно простить, только пока учитесь.

[~AsmodeuS~ 34]

друзья или наверное колеги нас просто тупо розводят уважаемый ttttt скорее всего это студент который прочитал книгу или начал читать Керниган, Ричи. Язык C и ему кажется что он открыл Америку хотяя думаю тут нет человека котоырй хотябы мельком но смотрел её.

 

А чтобы мы хотябы чтоыто увидели кроме тыкания в ....

вот простой пример в ABillS  можно построить больше 150  различных тарифных панов напигите прораму тестирования хотябы на 50 вариантов и тогда думаю к вам хотябы серйозно начнут относиться

 

 

[nightfly 1 222]

 2 ~AsmodeuS~

 

А чтобы мы хотябы чтоыто увидели кроме тыкания в ....

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

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

 

 

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

даст какой-либо результат отличный от предыдущих воплей про "мне вас жаль криворукие" и очередных попыток съехать на оракл.

[ttttt 195]

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

Ну да ладно. Сори, если кого-то обидел.

[~AsmodeuS~ 34]

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

Ну да ладно. Сори, если кого-то обидел.

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

[madf 279]

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

Ну да ладно. Сори, если кого-то обидел.

У нас с тестами. А у вас?

[dead 93]

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

[nightfly 1 222]

~AsmodeuS~

 

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

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

 

 

2 школотролль

 

Сори, если кого-то обидел.

Тихо тихо кисонька. Никого ты не способен обидеть.

[NiTr0 583]

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

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

 

от теории к практике

сегодня написали билинг все супер все работает,

 

через полгода нужны терминалы опять сидите вспоминаете что куда потом опять чтото нужно опять таже ситуация

 

и это в идеале

Код надо писать понятно и без грязных хаков в погоне за 0.5% производительности в редких ситуациях. И по максимуму использовать готовые наработки вместо изобретения велосипедов.

 

в настоящем мире так

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

 - много процессов довольно не оптимизированны и при малых нашрузка все хорошо при больших все вылазит боком

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

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

 

конечно готовіе решения тоже иногда имеют такие проблемы но если адекватные разработчики они очень быстро устраняются

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

 

так что писать самому это как покупка кота в мешке может там красивый кот,  а может там только кости

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

 

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

Відредаговано 2013-09-20 21:23:35 NiTr0

[dead 93]

Проблема в том, что нет четкого понятия биллинга. Это куча порой противоречивых требований - надежность, быстродействие, функционал, простота инсталяции, простота использования, интеграция с другими системами и еще куча. Где та середина, где то ОПТИМАЛЬНОЕ ТЗ? Его нет, потому что идеально спроектированный биллинг - это утопия. Его нет ни у кого, ни у одной фирмы со своей собственной разработкой. Понимаешь, вот мы все такие тут криворучки, годами пишем биллинги и не можем написать то, что бы всех удовлетворило. Ни мы, ущербные, ни одна иная крупная или мелкая фирма. Может  ты сейчас найдешь крутой биллинг, который идеальный? На оракле? С платной поддержкой? Его потянут домашние сети, для который он  нужен? То-то же. Биллинг - это неуловимый баланс, который мы тут ищем уже который год. У каждого свое мировозрение, свое видение и зачастую понять что нужно клиентам - это выпустить и получить от них фидбек "да, я это просил, но я понял, что это мне не надо". В своем новом биллинге, я учел предыдущий опыт

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

[NiTr0 583]

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

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

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

 

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

[dead 93]

Блин. Ну почему, я на протяжении уже нескольки я слышу подобные упреки, мол у биллингописателей мало знаний, плохо знают языки программирования и т.д. Хорошо, расскажу о себе. Программирую с 12 по 36 лет. Первый компьютер Вектор06ц. Язык программирования ассемблер. Что программировал - игры. Затем у папы на работе IBM 8086.  Язык программирования - асемблер. Программировал в основном игры (люблю их до сих пор). Из достижений - архиватор, который переплевывал zip -  инета тогда еще не было, выискивал крупицы обрывок статей по алгоритмам сжатия. Далее 95 винда. Делфи. Простейший САПР на делфи + бд  (это до 2000 года прошу заметить). В это же время работаю в областном пенсионном фонде, а там, вау, все на юниксе BSDI.  Автоматизирую сначала все скриптами на баше. Начинаю учить язык perl. Затем Си и С++. Программирую микроконтроллеры. Работаю в Банке Базис. Сталкиваюсь с Ораклом. Далее делаю свою сеть. Плотное изучение юниксов, сетевого оборудования и т.д. К продаже сети из 1500 абонов я был единственным админом, несколько серверных по нескольким районам города, объединенных оптикой, вифи (тогда оптика была ооочень дорога). Где-то есть видео как мы делаи модернизацию серверной - повыносили сервера и управляемые свичи так, что не было видно им конца и края. Далее я работаю в Приватбанке и делаю им персональную прошивку под  Wifi роутер  Fon. Далее дорабатываю одну из их платежных систем. Делаю свою вторую сеть. Сейчас работаю в Яндексе. В общем случае, кроме перечисленных языков я программировал на Форте (даже свой компилятор на него написал), Java, Php (лол, но это опыт) и кучу других мелких языков, например на ацком немощном pawn модули для Каунтер-страйк. Короче,

 

после этого всего, вы мне будете говорить, что у меня мало опыта, блеать? или я знаю мало языков программирования?

[~AsmodeuS~ 34]

 

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

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

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

 

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

 

 

звучит круто но порой бывает такая ситуация что уже существующие не удовлетворяют некоторые запросы или нужно тянуть целыйпоезд за собой когда нужно только маленький велосипед или например енжини не всегда так развиваются как надо

 

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

 

теперь по пунктам ABillS и вашим замечаниям

 

1 шаблонизатор не настолько продвинут как в других системах шалонов с одной стороны это недостаток с другой за 10 лет было 2 или 3 запроса дополнить функциями которых нет то есть это мене 1 процента пользоватлемя нужно. С нашей стороны это заменить свой шаблонизатор мене 1 кб на 50 кб чужёго и постоянно заним следить и тянуть за собой поезд с котрого нужно только 2 колеса а остальные колёса менее одного процента абонентам даже можно сказать менее 0.01 процента. Ну и самое главное эти функции не настоклько им и важны учитывая что платить за них никто не захотел (ну и тут логично если нет денег на это значит она не так и сильно нужна, а бесплатно никто не будет копать Ваш огород).

 

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

  - начать мне писать все по новой схеме уложив спать текущий проект. А это

      а) перепистаь десятки тис. строк кода только потомучто в будущем это вруг принесет результат. на переписывание уйдёт 3-6 месяцев. Для проекта это 6 месяцев без новых заказов соответсвенно я не получаю денег сотрудники без заплаты падение рейтинга системы и год на поднятие его. кто этот период профинансирует ? А вдруг в конечном итоге все пойдёт не так как планировалось и переписывание займёт больше времени кто все это время будет работать с имеющимися клиентами и как им обяснить что Ваши все нововведения появятся не не через 2-4 недели а через год два ? Так они просто плюнут и уйдут. Так что проект не может делать ревлюцию или переворот, а должен идти только строго вывереными, проверенными и спланироваными шагами.

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

 - третий вариант. на мой взлад самый разумный. Год назад Вы говорили что начинаете писать свою систему я предложил Вам сотрудничество. Прошёл год Вы так и не написали систему. Я предложил учитывая ваши наработки создать схему с одной двумя функциями для ABIllS чтобы я мог еволюционно их внедрить, на это Вы отправили мне коды Вашей системы которую по многим парамтерам я не могу внедрить. И выходит очень интересная ситуация как Вы писали на создание билинга Вам нужно несколько недель но для написания просто одной цепочки нужно времени как минимум в раз десять меньше но на неё у Вас по какихто причинах нет времени. А если бы Вы выделили время то эти нововедения появились бы в системе год назад, не нужно бы было начинать писать вам свою систему и все были бы в выиграше. И так что у нас имеется по третему варианту у Вас нет времени 1-2 недель чтобы написать одну цепочку и предложить более прогресивные вариант но хотите чтобы мы потратили  год на введение идей при этом получив не малые финансовые убытки.

 

так что видите критика может и существенная но учитывая остальные факторы она остаётся голыми словами так как на практике не извесно что принесут нововведения.

[NiTr0 583]

после этого всего, вы мне будете говорить, что у меня мало опыта, блеать? или я знаю мало языков программирования?

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

 

звучит круто но порой бывает такая ситуация что уже существующие не удовлетворяют некоторые запросы или нужно тянуть целыйпоезд за собой когда нужно только маленький велосипед или например енжини не всегда так развиваются как надо

 

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

Темплейт энжины обычно обладают обратной совместимостью...

 

1 шаблонизатор не настолько продвинут как в других системах шалонов с одной стороны это недостаток с другой за 10 лет было 2 или 3 запроса дополнить функциями которых нет то есть это мене 1 процента пользоватлемя нужно. С нашей стороны это заменить свой шаблонизатор мене 1 кб на 50 кб чужёго и постоянно заним следить и тянуть за собой поезд с котрого нужно только 2 колеса а остальные колёса менее одного процента абонентам даже можно сказать менее 0.01 процента. Ну и самое главное эти функции не настоклько им и важны учитывая что платить за них никто не захотел (ну и тут логично если нет денег на это значит она не так и сильно нужна, а бесплатно никто не будет копать Ваш огород).

Вы пробовали переделать ЛК под конкретный скин? Не-не, не сменить стиль текущего ЛК, а изрядно его перелопатить, слив часть пунктов меню на одну страничку, часть - исключив, часть - урезав наполовину? Когда часть кода генерится темплейт энжином, часть - хранится в темплейтах (в порядке вывода которых черт ногу сломит), часть - вообще генерится в смеси логики с выводом (index.cgi + modules/*/webinterface)?

 

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

  - начать мне писать все по новой схеме уложив спать текущий проект. А это

      а) перепистаь десятки тис. строк кода только потомучто в будущем это вруг принесет результат. на переписывание уйдёт 3-6 месяцев. Для проекта это 6 месяцев без новых заказов соответсвенно я не получаю денег сотрудники без заплаты падение рейтинга системы и год на поднятие его. кто этот период профинансирует ? А вдруг в конечном итоге все пойдёт не так как планировалось и переписывание займёт больше времени кто все это время будет работать с имеющимися клиентами и как им обяснить что Ваши все нововведения появятся не не через 2-4 недели а через год два ? Так они просто плюнут и уйдут. Так что проект не может делать ревлюцию или переворот, а должен идти только строго вывереными, проверенными и спланироваными шагами.

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

 - третий вариант. на мой взлад самый разумный. Год назад Вы говорили что начинаете писать свою систему я предложил Вам сотрудничество. Прошёл год Вы так и не написали систему. Я предложил учитывая ваши наработки создать схему с одной двумя функциями для ABIllS чтобы я мог еволюционно их внедрить, на это Вы отправили мне коды Вашей системы которую по многим парамтерам я не могу внедрить. И выходит очень интересная ситуация как Вы писали на создание билинга Вам нужно несколько недель но для написания просто одной цепочки нужно времени как минимум в раз десять меньше но на неё у Вас по какихто причинах нет времени. А если бы Вы выделили время то эти нововедения появились бы в системе год назад, не нужно бы было начинать писать вам свою систему и все были бы в выиграше. И так что у нас имеется по третему варианту у Вас нет времени 1-2 недель чтобы написать одну цепочку и предложить более прогресивные вариант но хотите чтобы мы потратили  год на введение идей при этом получив не малые финансовые убытки.

 

так что видите критика может и существенная но учитывая остальные факторы она остаётся голыми словами так как на практике не извесно что принесут нововведения.

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

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

Стоит это того или не стоит - решать вам. Но в текущей системе, по-моему, даже вы уже теряете контроль над кодом...

Відредаговано 2013-09-21 14:20:39 NiTr0

[dead 93]

 

после этого всего, вы мне будете говорить, что у меня мало опыта, блеать? или я знаю мало языков программирования?

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

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

 

Я бы хотел не привязываться к моему биллингу в таких общих рассуждениях, но поскольку есть выпады - приходится на них отвечать. Да, нодени - это компиляция многолетних требований. Из-за этого в нем многое негибко. Поэтому я и сделал новый биллинг нодени+, где это все учел и спроектировал по уму. Тем не менее, я не считаю, что предыдущая версия плоха - это отражение действительности, вернись назад - я все равно не смог бы сделать намного лучшего даже если бы вы мне из будущего советы давали. Я сейчас помню прошлое и помню эти требования. Кого парили те вещи, на которые сейчас ставят основные ставки? Да, никого. Никто не поставил бы современный биллинг, потому что на то время были совершенное иные требования.

 

Да, меня злят ваши упреки, при всем том, что я уверен, что мой код надежней вашего будет в любом проекте. Почему? Потому, что я задрот. Вы можете использовать лучшие техники, лучшие фреймворки, языки, субд и т.д., но мой код будет надежнее и функциональнее вашего. Да, я такой самоуверенный. Я повидал на своем веку дохренища кода. И под тестами, и всеми лучшими техниками. И все равно в 99% случаев это остой, в котором я находил и ошибки и слабые места. А у таких теоретиков как вы, скорее всего ошибок будет в разы больше, ибо опыт в программировании - это постоянное программирование. Чем вы можете похвастаться? Чтением умных книжек?

[lemosh 59]

Перечитал топик, так ни одного внятного ответа не увидел на вопрос поднятый ТС.

Взрослые дядьки ведутся на поводу студентов-теоретиков и продолжают мерятся пи""""ми...

 

По теме, любой биллинг имеет право на жизнь, у каждого есть много плюсов и минусов.

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

 

Когда начинал строить свою сеть, работал (наверно как и многие) без биллинга, на ломанном керио

Захотелось автоматизации, узнал про микбилл и микротик...

Пообщавшись с ребятами на форуме с горем пополам установил себе микбилл 1.03 фри версию (давно это было)

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

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

.

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

 

недавно подошел к лимиту бесплатной версии, решил приобрести платную. Перенес на новый сервер биллинг, порадовал скрипт для установки на цент_ос - запустил установочный файл, минут 15-20 подождал и полностью рабочий биллинг на новом сервере без особого геморроя... Перенес старую базу, дал доступ к серверу, активировали лицензию и все работает ок

 

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

[NiTr0 583]

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

Скажите, адекватный разработчик будет писать биллинг, включая резидентное ядро, на php, у которого кривой сборщик мусора, а утечки памяти - нормальное явление? А может, биллинг без foreign ключей в БД и без транзакций (ну подумаешь, деньги снялись а услуга забыла активироваться т.к. СУБД лагонула) - это нормально? Не, оно работает, почти без проблем, но...

 

Я бы хотел не привязываться к моему биллингу в таких общих рассуждениях, но поскольку есть выпады - приходится на них отвечать. Да, нодени - это компиляция многолетних требований. Из-за этого в нем многое негибко. Поэтому я и сделал новый биллинг нодени+, где это все учел и спроектировал по уму. Тем не менее, я не считаю, что предыдущая версия плоха - это отражение действительности, вернись назад - я все равно не смог бы сделать намного лучшего даже если бы вы мне из будущего советы давали. Я сейчас помню прошлое и помню эти требования. Кого парили те вещи, на которые сейчас ставят основные ставки? Да, никого. Никто не поставил бы современный биллинг, потому что на то время были совершенное иные требования.

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

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

От того - сдается мне, что вы сильно лукавите...

 

Да, меня злят ваши упреки, при всем том, что я уверен, что мой код надежней вашего будет в любом проекте. Почему? Потому, что я задрот. Вы можете использовать лучшие техники, лучшие фреймворки, языки, субд и т.д., но мой код будет надежнее и функциональнее вашего. Да, я такой самоуверенный. Я повидал на своем веку дохренища кода. И под тестами, и всеми лучшими техниками. И все равно в 99% случаев это остой, в котором я находил и ошибки и слабые места. А у таких теоретиков как вы, скорее всего ошибок будет в разы больше, ибо опыт в программировании - это постоянное программирование. Чем вы можете похвастаться? Чтением умных книжек?

Ну что ж, мериться так мериться. Да, мой опыт несколько поменьше вашего, всего каких-то лет 15, но за это время писал на разных языках (это и асм, включая х86, 8051, AVR, и паскаль/делфи, и С/С++ включая Qt framework, голое WinAPI, RTOS, эксперименты с драйверами ядра и модулями нетфильтра linux, и перл, и питон, и чуток тикля, и яваскрипт, ну и шеллскрипт ессно - не тянуть же в embedded перл/питон), начиная от небольших утилит/библиотек оканчивая скада-системами. И да, чем дальше, тем больше я убеждаюсь, что лучший код - не написанный. Т.е., чем больше юзается адекватных популярных библиотек/фреймворков на замену собственноручно писаным велосипедам, тем легче поддержка кода в итоге, и легче разработка. Особенно - если к разработке придется привлекать еще кого-то.

 

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

[dead 93]

Скажите, адекватный разработчик будет писать биллинг, включая резидентное ядро, на php, у которого кривой сборщик мусора, а утечки памяти - нормальное явление? А может, биллинг без foreign ключей в БД и без транзакций (ну подумаешь, деньги снялись а услуга забыла активироваться т.к. СУБД лагонула) - это нормально? Не, оно работает, почти без проблем, но...

Я не понимаю о каком биллинге вы говорите. В моем биллинге не написано ни строчки на php. Также там используются транзакции и не один раз, а на постоянной основе. Как я уже сказал, вы упрекаете по цепочке, при этом хотя я и опровергаю ваши домыслы, я осознаю, что все равно в проигрыше - "осадочек остается". Но мне интересно подискутировать, я давно не велся на провокации, так что готов продолжать бой до выяснения истины

 

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

вы бы знали сколько раз иногда было, что я произвел рефакторинг, потом через месяц тестов осознал слабые места, снова рефакторинг и так вылизываю почти до идеала. Можно пробежаться по коммитам и посмотреть это воочию. Однако вы же уверены, что мы тут нифига не рефакторим, просто вам так кажется и все.

 

 

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

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

 

---

 

Я прошу прощение у автора топика, что я основной, кто засоряет эту тему. Так уж получилось, что я повелся на троллинг, но почему бы и нет? Может кому-то интересно как кухня устроена изнутри...

[dead 93]

Перечитал топик, так ни одного внятного ответа не увидел на вопрос поднятый ТС.

Вы ж понимаете, что разработчики биллингов не будут в этой теме рекламировать свои продукты, это не этично. Тема плавно перешла в троллинг (на мой взгляд), в любом случае все свелось к критике, из которой можно свое рациональное зерно вынуть Відредаговано 2013-09-21 20:02:53 dead

[NiTr0 583]

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

Микбилл, писаный на пхп. Абиллс (который весьма недавно обзавелся транзакциями, и то - лишь местами, а foreign ключи до сих пор то ли в todo, то ли в "нафиг нужно"). Думал, вы угадаете продукт из описаных "особенностей реализации".

 

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

Вы какбы сами впряглись, я вас не тянул и ваш биллинг вообще не упоминал. А раз зацепило - очевидно, есть на то причина.

 

вы бы знали сколько раз иногда было, что я произвел рефакторинг, потом через месяц тестов осознал слабые места, снова рефакторинг и так вылизываю почти до идеала. Можно пробежаться по коммитам и посмотреть это воочию. Однако вы же уверены, что мы тут нифига не рефакторим, просто вам так кажется и все.

Я вашего проекта какбы не видел (и не присматривался к нему), и конкретно о нем не говорил. Я говорил о других околосетевых проектах. Как опенсорсных, так и платных (в т.ч. довольно дорогих типа ned2).

[~AsmodeuS~ 34]

 

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

Микбилл, писаный на пхп. Абиллс (который весьма недавно обзавелся транзакциями, и то - лишь местами, а foreign ключи до сих пор то ли в todo, то ли в "нафиг нужно"). Думал, вы угадаете продукт из описаных "особенностей реализации".

 

 

странно знакомы с проектом уже куча лет и не заметили что модуль документов ядро с оплатами и снятиями уже давно с foreign  ключами. Все отсальное не могу перевети так как еще есть абоненты которыепользуются версиями которые не поддерживают данный функционал. Жаль еонечно что Вы не смотрели другие системы с переспективы базы много "интересного" узнали бы. К Вашим советам я всегда прислушиваюсь но не всегда могу реализировать иза объёма обязательств перед клиентами.