hiller Опубликовано 24 августа, 2009 · Жалоба Некий SQL injection. Хаха три раза. Типа нельзя реверснуть гуевое приложение и сделать то же самое...Э-ммм... Ты про что? Я про то, что параметры передваемые в SQL-запрос подлежат обязательной проверке на валидность и экранированию, в обсуждаемом WebUI это не было сделано, либо сделано но не полностью. Я ничего не говорил про GUI, хоть и считаю, что самое правильное в данном случае решение- WebUI. C GUI возникают дополнительные вопросы с безопасностью, с мультиплатформенностью и т.д. и т.п. В правильном интерфейсе injection невозможен.Сам такие интерфейсы пишу, в которых сделать injecton невозможно. Понятно, что все валидейтится, экранируется и т.д. и т.п. Круто сказано. Поясните мне - тупому, как можно выделить бизнес-логику таким образом, чтобы решить проблему с безопасностью, о которой я говорил выше?Также, как и везде. Интерфейс не должен общаться с базой напрямую. В качестве костылей конечно подходит валидация данных, экранирование запросов, параметризированные запросы и хранимые процедуры, вариантов множество. Да, вот только все эти "костыли" не способны ограничить доступ пользователя только к разрешенным ему записям (не полям, а записям) на уровне БД. Так что, интерфейсу один фиг придется общаться с базой напрямую... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Agile Опубликовано 24 августа, 2009 · Жалоба Да, вот только все эти "костыли" не способны ограничить доступ пользователя только к разрешенным ему записям (не полям, а записям) на уровне БД.Для этого в нормальных БД есть Row Level Security. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Paparaцo Опубликовано 24 августа, 2009 · Жалоба Если говорить о коммерческой стороне вопроса (насколько я понял этот биллинг предлагается к продаже), то: 1. Не проработаны юридические вопросы (договор, авторское право и т.п.) 2. Не проработаны маркетинговые вопросы (сайт, дизайн интерфейсов и т.п.) 3. Отсутствует сертификат соответствия (интересно, как без оного данная АСР используется в Астрахань-Телком) ай-яй-яй :) 4. Непонятен формат и порядок оказания поддержки, время реакции. 5. Непонятны возможности разработчика допиливать АСР под требования конкретного оператора. 6. По техническими вопросам много неясного, нужно больше информации. Итого: в таком виде решение НЕ ПРОДАВАЕМОЕ в принципе. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
visir Опубликовано 24 августа, 2009 · Жалоба В настоящее время система обслуживает более 7000 телефонов и около 3000 абонентов интернет. Хотя-бы потому, что благодаря использованию динамических технологий, программа очень быстро обрабатывает реально большие объемы данных. При этом, нагрузка radius сервера в ЧНН доходит 50-80 апдейтов в секунду + 50 юзеров работает с базой + NetFlow, декодирование cdr и прочее. Все крутится, ничего не тормозит. Также, функциональные возможности нашей программы позволяют использовать ее любым оператором связи. Все есть, все отлажено.Большие объемы данных ? Что же будет, когда число юзеров зашкалит за 100к.. Эх, блин.Был у нас тут постгресс. с 2003 по 2006 год. До сих пор мучаемся когда пытаемся оттуда вытащить старые звоночки за те периоды. Большего г*^& в жизни видеть не приходилось. Причина: МЕДЛЕННЫЙ. Все остальное насчет него мало интересно. Напрасно на самом деле. Любую бд можно заставить тормозить, неумелым использованием. Постгрес отлично работает, если его использовать с умом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vampyr Опубликовано 25 августа, 2009 · Жалоба Вы переработайте весь текст на сайте... Мы наоборот старались писать понятным простым языком. "Потенциальный клиент" должен знать как работает система и за что он будет платить. Когда мы в свое время искали биллинг, мы не могли найти нужной информации на сайтах, предлагающих свой биллинг. (извините за тавтологию) Да, красиво, да, умно сказано, написано, но по сути ничего толкового нет. Вот мы и напоролись ... Поэтому о своем биллинге решили рассказать как можно больше и доступнее. Очень похоже на мою ситуацию... Администрация пищит от самописного и, кстати, сертифицированного недавно биллинга, который я видеть не могу. Это документооборот просто какой-то. А мне пришлось писать свое, зато оно управляет железом и в нем все видно. Но администрация от него нос воротит и говорит что это не нужно. Вот так и сидим, техотдел в моем биллинге, клиентский в своем... А директорат, кстати, один в моем, другой в своем. БУГОГА. Мой вам совет... Не обращайте вы внимания на понятность языка. Биллинг ставить и внедрять будет тот кто уже написал свой или переписал чужой. Это статистика 70% провайдеров. А ваше желание умилить чужого гендира простотой... Вот это ношение с "щасьем ф торбе" (сам такой) - очень хорошо, но не стоит перебирать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 25 августа, 2009 · Жалоба А мне пришлось писать свое, зато оно управляет железом и в нем все видно. Но администрация от него нос воротит и говорит что это не нужно. Вот так и сидим, техотдел в моем биллинге, клиентский в своем... А директорат, кстати, один в моем, другой в своем. БУГОГА. Биллинг не должен управлять железом, это дело NMS. Биллинг - это учет услуг и тарификация. В директорате видать умные люди сидят. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hiller Опубликовано 25 августа, 2009 · Жалоба Есть ряд задач, причем технических задач связанных с управлением оборудованием, которые наиболее удобно реализовывать в интерфейсе биллинговой системы. Например у нас показываются статусы портов, статистика по ошибкам, графики загрузки, мак-адреса, осуществляется ping/arping, traceroute, показываются статические маршруты в vlan/клиента, bgp-сессии и многое другое. Весь этот функционал позволяет службам технической поддержки, а в отдельных случаях, продвинутым манагерам более эффективно работать с клиентом, меньше его мурыжить переключением с отдела на отдел и т.п. Содержать отдельную системы для инженеров и отдельную для манагеров желания нет, нам хватает бухгалтерии, с которой только недавно сделали нормальный обмен данными... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vampyr Опубликовано 25 августа, 2009 · Жалоба А мне пришлось писать свое, зато оно управляет железом и в нем все видно. Но администрация от него нос воротит и говорит что это не нужно. Вот так и сидим, техотдел в моем биллинге, клиентский в своем... А директорат, кстати, один в моем, другой в своем. БУГОГА. Биллинг не должен управлять железом, это дело NMS. Биллинг - это учет услуг и тарификация. В директорате видать умные люди сидят. Ну да. Конечно. давайте будем отдел сисадминов дергать на отключение неоплативших клиентов 1-го января, в праздники и выходные. И вообще по каждому писку на клиента бегом к сисадминам. А потом удивляемся почему они посылают вас НА и не берут мобильники когда действительно надо. Биллинг должен уметь ВСЕ. И в первую очередь уметь отключить клиента в 5 утра потому что он перекачал больше оплаченных Мб. Это деньги, уважаемый. Всего-лишь деньги. Меньше дежурных, меньше зарплаты, меньше оплат переработок, меньше текучка и конфликты. Сами после этого думайте кто сидит в директорате. показываются статусы портов, статистика по ошибкам, графики загрузки, мак-адреса, осуществляется ping/arping, traceroute, показываются статические маршруты в vlan/клиента, bgp-сессии и многое другое. Весь этот функционал позволяет службам технической поддержки, а в отдельных случаях, продвинутым манагерам более эффективно работать с клиентом Вово. и это тоже. Правда зачем трейсы... А вот статусы портов, арп и пинг точно надо. Правда до пинга у меня руки еще не дошли. А уж переоценить автоматические блокирование-разблокирование по дате, по кредитоспособности и вообще. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 25 августа, 2009 · Жалоба Ну да. Конечно. давайте будем отдел сисадминов дергать на отключение неоплативших клиентов 1-го января, в праздники и выходные. И вообще по каждому писку на клиента бегом к сисадминам. А потом удивляемся почему они посылают вас НА и не берут мобильники когда действительно надо. Биллинг должен уметь ВСЕ. И в первую очередь уметь отключить клиента в 5 утра потому что он перекачал больше оплаченных Мб. Это деньги, уважаемый. Всего-лишь деньги. Меньше дежурных, меньше зарплаты, меньше оплат переработок, меньше текучка и конфликты. Сами после этого думайте кто сидит в директорате. Просто у Вас неправильно поставлены бизнес-процессы, и Вы пытаетесь это компенсировать костылями в биллинге, влепив в него функционал NMS, ServiceDesk, CRM и всего остального. Причем с некой критической массы этого функционала Вы не сможете его не то, что развивать, а даже поддерживать. Безопасность требует, чтобы технический персонал не имел никакого доступа к биллингу, кроме тех, кто отвечает за его работоспособность, иначе очень быстро вся ваша информация утечет к конкурентам. А чтобы у Вас не возникали фантазии про отключения 1го января ( когда админы скорее всего не то, что бегать, а даже шевелиться не могут ) биллинг должен иметь открытые интерфейсы, для интеграции с другими системами. Которым он будет либо давать команды на исполнение, либо выдавать необходимую техническую информацию по запросу с контролем доступа. Вово. и это тоже. Правда зачем трейсы... А вот статусы портов, арп и пинг точно надо. Правда до пинга у меня руки еще не дошли. А уж переоценить автоматические блокирование-разблокирование по дате, по кредитоспособности и вообще. :-))))))))))))))))))))))))))))) rotfl Печальная участь UTM4 перлописателей ничему не учит... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vampyr Опубликовано 25 августа, 2009 (изменено) · Жалоба Просто у Вас неправильно поставлены бизнес-процессы, и Вы пытаетесь это компенсировать костылями в биллинге, влепив в него функционал NMS, ServiceDesk, CRM и всего остального. Причем с некой критической массы этого функционала Вы не сможете его не то, что развивать, а даже поддерживать. Вот тут написана откровенная чушь, извините. Сколько же систем обеспечивают вашу работоспособность? И куда исчезнет что при увольнении одного из спецов по данной конкретной системе? Опытом и граблями доказано что управлять максимумом должна минимальная система. При чем тут костыли, я не понимаю... Функционал вы называете костылями? Судя по всему, это пишет очередной отучившийся по америкосской системе "руководитель". Позвольте заметить, у нас другая страна и другие реалии. Биллинг - это и есть и сервисдеск и NMS и CRM в одном флаконе в узкой специфике конкретной работы с пользователями. Именно узкая специфика позволяет создавать примитивные централизованные автоматизированные системы управления, которые приводят 1 - к легкости их администрирования и передаче при смене администратора, 2 - минимальным требованиям к знаниям администрирующего персонала, 3 - Все в одном месте и написано в одном стиле и одними правилами. Это залог 1 и 2. Все что касается отложенных задач, а именно документооборот, выписка счетов и т.д. может обеспечиваться чем угодно и в любом количестве, но система оперативного управления сетью должна быть проста, эффективна и зависеть только от себя. Я понимаю что это не вписывается в MBA курс, но еще раз повторюсь, "управление бизнес процессом" не имеет никакого отношения к управлению сетью с 1000 не подчиняющихся вам пользователей. К тому же, описанное вами "биллинг должен иметь открытые интерфейсы, для интеграции с другими системами" - абсолютно то же самое, о чем пишу я, только развесистое как клюква с толпой админов или одним незаменимым. Это, как раз, и есть криво поставленная работа. Результат тот же, а вот реализация, извините. Безопасность требует, чтобы технический персонал не имел никакого доступа к биллингу, кроме тех, кто отвечает за его работоспособность, иначе очень быстро вся ваша информация утечет к конкурентам. Информация утекает к конкурентам немного другим способом. К тому же невозможно не дать техническому персоналу не видеть данные клиента. Тоже чушь написали, уважаемый. Как техники будут работать на линии???? Без данных. А безопасность данных вообще обеспечивается правами пользователя в биллинге и другими типами защиты данных. Как показывает практика, тот кто может обойти примитивную защиту вполне способен и без всяких биллингов унести всю базу, да еще и красиво оформить ее для всех желающих. Вы работаете со спецами определенного немаленького уровня! Кажется, вы об этом забываете. Печальная участь UTM4 перлописателей ничему не учит... Писать можно хоть на бейсике. Безопасность не в том на чем написано, а в человеческом факторе. И все эти россказни про то какую невзламываемую систему кто-то там написал... Биллинг не должен быть виден снаружи. Он должен быть виден тем кому вы доверяете. А сломать можно абсолютно все. И еще забыл... У меня при падении системы восстановление производится посредством укладывания на место всего лишь пары десятков килобайт конфигов и пары десятков мегов базы данных + мой биллинг (100 кб тар). Всей сети. Даже если все свичи и рутеры сброшены в дефолт (естественно придется прописать им ип и логины с паролями или другой тип авторизации, но не более). А у вас с вашей клюквой? А ведь это тоже деньги... Я могу менять свичи и рутеры как перчатки и для этого надо места для бекапа всего этого мизер, опереационная система для биллинга - любая, мощность биллингмашины - любая (в разумных пределах), биллингмашина, обеспечивающая всю сеть - 1. И наконец, уровень сисадмина при уже готовом и установленном биллинге - умение двигать мышью, при установке с 0 с учетом что для себя у меня скрипты управления есть - способность установить *nix систему по дефолту, веб сервер и пару модулей перл из портов или рпм. А у вас? И это тоже деньги. Изменено 25 августа, 2009 пользователем vampyr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 25 августа, 2009 · Жалоба Биллинг - это и есть и сервисдеск и NMS и CRM в одном флаконе в узкой специфике конкретной работы с пользователями. Вот с такой подмены понятий все и начинается. Удачи Вам в изобретении пятиколесных велосипедов, юноша. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martin74 Опубликовано 25 августа, 2009 · Жалоба vampyr, это у вас сеть маленькая.... Подрастете - перечитайте собственный пост... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vampyr Опубликовано 25 августа, 2009 (изменено) · Жалоба Биллинг - это и есть и сервисдеск и NMS и CRM в одном флаконе в узкой специфике конкретной работы с пользователями. Вот с такой подмены понятий все и начинается. Удачи Вам в изобретении пятиколесных велосипедов, юноша. Ох уж мне эти "суперумные" руководители... У меня 10-ти летний опыт руководства ИТ отделом в организациях с больше 20 филиалов по стране, не считая по городу, (3 шт) и т.д. 2 провайдерские конторы 1 сисадмин, 2 - нач отд. Одна программерская организация, в которой я держал все платформы, существующие в мире на начало 21 века. 20 лет суммарносисадминско-начальничего стажа. И юношей хотел бы остаться... Чет не получается. И я знаю вашу позицию. И ни разу при мне в организации такие как вы не выигрывали споров у учредителей ни в финансовом, ни в техническом вопросе. Это тут у нас языкотреп, а реале все гораздо проще и сложнее. И подчиняется цифрам и эффектам от демонстраций. vampyr, это у вас сеть маленькая.... Подрастете - перечитайте собственный пост... 5000 клиентов много? Все тот же 1 фревый сервак, правда 4 ядра и оперативки под завязку и под базу данных отдельный ресурс. Больше не видел. Увижу - приду и перечитаю, конечно. Но проблема в том что организации с больше 5000 пользователей не нужен бесплатный самописный биллинг. Изменено 25 августа, 2009 пользователем vampyr Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 25 августа, 2009 · Жалоба Но проблема в том что организации с больше 5000 пользователей не нужен бесплатный самописный биллинг. почему вы так думаете и в чём именно заключается проблема? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vampyr Опубликовано 25 августа, 2009 · Жалоба Но проблема в том что организации с больше 5000 пользователей не нужен бесплатный самописный биллинг.почему вы так думаете и в чём именно заключается проблема? Каждый свое дело делает сам ессно. Но при таком количестве клиентов можно уже заключить договор на эксклюзивную поддержку любого программного продукта, биллинга или еще чего-то, написанием которого занимается группа программистов в пределах договора и выполняет определенные работы в определенные сроки. А не сидит сисадмин и ковыряя в носу пишет на барсике какую-то поделку. Это спецы другого класса, софт другого класса. Если ваш сисадмин говорит что он крутой програмер и одновременно крутой сетевик, цискарь и т.д. и т.п. - отправьте его разговаривать с зеркалом. Крутой кто-то даже крутым геймером быть параллельно не может. Потому что настоящий профессионал 100% рабочего и, возможно, часть нерабочего времени занимается своей областью и только ей. Спец в 2-х областях должен тратить 200% своего времени. И т.д. Это не я придумал, это жизнь такая. Каждая из затрагиваемых при поддержании провайдерской сети задач очень объемна и "текуча". В пределах нескольких тысяч пользователей это еще терпимо, но дальше требуется профессиональное знание по оптимизации сырцекода, работы с бд и т.д. Как и знание рутеров, будь то циска или фря. Иначе вы получите кластер из 4-х ядерных суперсерверов с загрузкой 100%. Ну как-то так. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 25 августа, 2009 · Жалоба vampyr - ну к примеру я написал в свое время не один биллинг, и в то же время я админ. Крутым себя назвать не могу, но думаю справляюсь с задачами по знаниям. К примеру я могу настроить высокопроизводительный роутер, прокси, шейпер, и в то же время написать на C+PHP медийную систему дистрибуции видеоконтента для связи гос. органов с ТВ компаниями. И уверен в том, что напишу лучше, чем корявые и глюкавые поделки от "производителей биллингов". Единственным аргументом в их пользу может являться какой-то обьемный в плане трудозатрат функционал и сертификация. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martin74 Опубликовано 25 августа, 2009 · Жалоба а никто не учитывает еще и проблему перехода на другой биллинг в процессе роста компании? Не так уж и просто все... И персонал переучить, и данные перенести, и пользователям объяснить.... Я не скажу, что это нерешаемые проблемы. Но достаточно сложные... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hiller Опубликовано 25 августа, 2009 · Жалоба Вово. и это тоже. Правда зачем трейсы... 1. Когда роутим сетку на клиента, бывает полезно сделать трейс до какого-либо выданного адреса, после чего сообщить клиенту, что у него что-то отвалилось за таким-то роутером. 2. Когда покупаешь L3 у другого оператора, полезно увидить на трейсе, что до твоего роутера в другом населенном пункте пакетики идут правильно, а не через null или другую резервную *опу. 3. Во всех перечисленных случаях, полезно видеть задержки возникающие на магистральных маршрутизаторах и вовремя понять, где проблема. Но проблема в том что организации с больше 5000 пользователей не нужен бесплатный самописный биллинг.почему вы так думаете и в чём именно заключается проблема? Каждый свое дело делает сам ессно. Но при таком количестве клиентов можно уже заключить договор на эксклюзивную поддержку любого программного продукта, биллинга или еще чего-то, написанием которого занимается группа программистов в пределах договора и выполняет определенные работы в определенные сроки. А не сидит сисадмин и ковыряя в носу пишет на барсике какую-то поделку. Это спецы другого класса, софт другого класса. Наша разработка оказалась весьма работоспособной даже на относительно большом кол-ве абонентов и никто не мешает масштабировать ее дальше. Наверно все зависит от того, кто проектировал систему. Если проектировалось изначально под большие нагрузки, то проблем быть не должно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jab Опубликовано 25 августа, 2009 · Жалоба Ох уж мне эти "суперумные" руководители... У меня 10-ти летний опыт руководства ИТ отделом в организациях с больше 20 филиалов по стране, не считая по городу, (3 шт) и т.д. 2 провайдерские конторы 1 сисадмин, 2 - нач отд. Одна программерская организация, в которой я держал все платформы, существующие в мире на начало 21 века. 20 лет суммарносисадминско-начальничего стажа. Ну если Вы за 20 лет даже не научились терминологии, и путаете АСУП с биллингом, то ничего кроме жалости это вызвать не может. Написать биллинг - очень просто, этим не занимался только ленивый, но это лишь 10% от трудозатрат в продукте. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vampyr Опубликовано 25 августа, 2009 · Жалоба vampyr - ну к примеру я написал в свое время не один биллинг, и в то же время я админ. Крутым себя назвать не могу, но думаю справляюсь с задачами по знаниям.К примеру я могу настроить высокопроизводительный роутер, прокси, шейпер, и в то же время написать на C+PHP медийную систему дистрибуции видеоконтента для связи гос. органов с ТВ компаниями. Ну я ж не писал что вот одна задача, в остальном - все. Ключевая фраза вот: "думаю справляюсь с задачами по знаниям". Но в определенный момент этих знаний не хватит.... И часто тот кому этих знаний не хватает этого просто не замечает. Я тоже и то и се, что-то лучше, что-то хуже... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vampyr Опубликовано 25 августа, 2009 · Жалоба Вово. и это тоже. Правда зачем трейсы... 1. Когда роутим сетку на клиента, бывает полезно сделать трейс до какого-либо выданного адреса, после чего сообщить клиенту, что у него что-то отвалилось за таким-то роутером. Наша разработка оказалась весьма работоспособной даже на относительно большом кол-ве абонентов и никто не мешает масштабировать ее дальше. Наверно все зависит от того, кто проектировал систему. Если проектировалось изначально под большие нагрузки, то проблем быть не должно. Про трейс понял, просто мне кажется это слишком громоздким. Руками привычнее. К тому же если линков много и оно все на динамике сам не сразу сообразишь через что оно должно идти... Шучу. И кто и изначально на что. Я пишу свое поделие на "до среднего" и "большие организации". Так вышло что больше не надо. Вы писали сразу под объем. Вообще-то мы жуем резину, можно написать что угодно и предложить что угодно. Я считаю что за все надо сказать спасибо, но никто не заставляет этим пользоваться. Или просто взять и переписать. Никаких проблем... Ну если Вы за 20 лет даже не научились терминологии, и путаете АСУП с биллингом, то ничего кроме жалости это вызвать не может. Написать биллинг - очень просто, этим не занимался только ленивый, но это лишь 10% от трудозатрат в продукте. Да-да. Когда нечего написать обычно прячутся за терминологию. Или разыскивают орфографические ошибки. Или еще че. Вдаваться в демагогии что для кого что значит не собираюсь. Для меня асуп не имеет никакого отношения к биллингу т.к. это автоматизированная система управления процессами, а никак не железом например. Но и "биллинг" употребляю слегка неправильно. Ну что делать.... Вот такой вот я дурак.... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
martin74 Опубликовано 25 августа, 2009 · Жалоба а вы высшее образование по специальности "Автоматизированное управление производственными процессами" получите... Глядишь - окажется, что все СУЩЕСТВУЮЩИЕ наработки в области АСУТП можно применить и к провайдеру... И не надо изобретать толпу велосипедов... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hiller Опубликовано 25 августа, 2009 (изменено) · Жалоба а вы высшее образование по специальности "Автоматизированное управление производственными процессами" получите... Глядишь - окажется, что все СУЩЕСТВУЮЩИЕ наработки в области АСУТП можно применить и к провайдеру... И не надо изобретать толпу велосипедов... ...а потом сравните с тем, что у вас есть сейчас и поймите, что это было менее громоздко, требовало меньших ресурсов и не зависило от человеческого фактора и людей со специальным образованием. Причем общий смысл заключается в том, что те кто получил такое образование, имеют одну точку зрения, а те кто не получил, а дошел до всего этого на практике, с другой. При этом задача решается обоими способами. А оценить, какой из подходов лучше не выйдет по причине мышления в разных плоскостях... Изменено 25 августа, 2009 пользователем hiller Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vampyr Опубликовано 25 августа, 2009 · Жалоба а вы высшее образование по специальности "Автоматизированное управление производственными процессами" получите... Глядишь - окажется, что все СУЩЕСТВУЮЩИЕ наработки в области АСУТП можно применить и к провайдеру... И не надо изобретать толпу велосипедов... Второе высшее по специальности я получил в 35. Можно больше не буду, а? Дороговато для старика. Дело не в каких-то там незнаниях... Если бы мы когда-то в 90-х, когда профессура ВУЗов не знала того что знали мы, такого рода темы обсуждали в таком тоне... Не провайдерами бы кишели города, а каменными топорами. Потому что мы до всего доходили сами. А потом некоторые из нас пошли учить вас. Неужели кто-то думает что высокомерный тон и хамство может привести к чему-то хорошему? Знаешь - расскажи если спросили. Не спросили - объясни и поправь. Что в этом такого? И могу заверить, все наработки в любой области можно применить к всяким разным другим. Просто когда пишешь такого рода ответы неплохо бы помнить что кто-то знает не меньше тебя, кто-то в десятки раз больше. Некрасиво получается... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hiller Опубликовано 25 августа, 2009 · Жалоба Ну я ж не писал что вот одна задача, в остальном - все. Ключевая фраза вот: "думаю справляюсь с задачами по знаниям". Но в определенный момент этих знаний не хватит.... И часто тот кому этих знаний не хватает этого просто не замечает. Я тоже и то и се, что-то лучше, что-то хуже... Недостаток знаний будет заметен, когда вы не сможете решить какую-либо из текущих задач. В этих случаях надо продолжать совершенствовать свои знания и продукт вами созданый. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
