Основной критерий выбора технологий программирования: "Чтобы вас можно было заменить на васю, не знающего языка и он мог прочесть код": http://ugenk.livejournal.com/188023.html
Очередной яркий пример программиста, который не занимается эксплуатацией своих продуктов. Отдавать на 100% поддержку на откуп производителю - плохо, очень плохо. У местных кадров должна быть возможность хотя бы примерно понять, что там внутри системы происходит, а не на каждый чих открывать problem management request за многотыщбаксов.
Админы/эксплуатационники которые смотрят в код купленной системы - это пиздец от входа. Не говоря уже о том, чтобы его править. Должны быть логи, удобные ручки для админов и прочее. Но не код.
Очень редко, но приходится таки лазить в код. В моей практике такие случаи возникают раз-два в год. Восторга от этого не испытываю, и делается это только в случае "пиздец-пиздец мы все умрем", после чего в любом случае пинается суппорт раработчика.
Дело заказчика - описать требования, дать денег и получить продукт. Затем он должен платить абонентскую плату, за поддержу и некоторые изменения. Чтобы получить исходники - он вообще должен дать охулиард денег. И уж точно не его дело, на чем будет написан продукт. Есть граничные условия - где и в каких условиях сделланое должно работать, и не более.
>problem management request за многотыщбаксов Не обеднеют.
Если с точки зрения программиста-админа-шивы многорукой у заказчика - то да. А с точки зрения торговли ПО - не надо ничего открывать, а еще лучше - сдавать в аренду, SAAS делать.
>Затем он должен платить абонентскую плату, за поддержу и некоторые изменения.
проблема в том, что зачастую ответа от ТП приходится ждать по несколько дней, а пиздец - он уже здесь
>Чтобы получить исходники - он вообще должен дать охулиард денег.
если речь идет про десктопную бухгалтерию на дельфи - ради бога.
>И уж точно не его дело, на чем будет написан продукт. Есть граничные условия - где и в каких условиях сделланое должно работать, и не более.
при условии, что разработчик берет на себя ответственность за кривую работу софта. В противном случае команда экспертов со стороны заказчика имеет право говорить на чем писать, какие технологии использовать, и даже какую методологию разработки использовать (дада, здесь любители скрамов дружно встали и вышли)
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
no subject
no subject
no subject
Вы
>согласен. каким именно образом реализация системы на erlang эту возможность отнимает?
Там ребе метакласс ниже пояснил. Я как админ заказчика в гробу видел разбираться в функциональщине, мне своей головной боли хватает
no subject
2. как вы представляете использование собственного софта разработчиками оперденей/SCADA/etc?
«но ты же компьютерщик!»©ну и не разбирайтесь. пусть работу программиста делает, страшно подумать, программист.no subject
Должны быть логи, удобные ручки для админов и прочее. Но не код.
no subject
no subject
no subject
Дело заказчика - описать требования, дать денег и получить продукт. Затем он должен платить абонентскую плату, за поддержу и некоторые изменения. Чтобы получить исходники - он вообще должен дать охулиард денег. И уж точно не его дело, на чем будет написан продукт. Есть граничные условия - где и в каких условиях сделланое должно работать, и не более.
>problem management request за многотыщбаксов
Не обеднеют.
no subject
Вот imho -- closed source надо запретить. (замечу не пропиетарщину, а именно закрытие исходников -- купил получи исходники)
no subject
no subject
Иначе в итоге мы имеет опердени в досбоксе.
no subject
проблема в том, что зачастую ответа от ТП приходится ждать по несколько дней, а пиздец - он уже здесь
>Чтобы получить исходники - он вообще должен дать охулиард денег.
если речь идет про десктопную бухгалтерию на дельфи - ради бога.
>И уж точно не его дело, на чем будет написан продукт. Есть граничные условия - где и в каких условиях сделланое должно работать, и не более.
при условии, что разработчик берет на себя ответственность за кривую работу софта. В противном случае команда экспертов со стороны заказчика имеет право говорить на чем писать, какие технологии использовать, и даже какую методологию разработки использовать (дада, здесь любители скрамов дружно встали и вышли)