Языки программирования? По барабану.
По мотивам срачей с ребе айседом на тему "LISP/Clojure vs Java vs C++ vs Ruby vs Haskell" запишу свои тезисы, чтобы не забыть:
0) Выбор языка программирования - по сараю. Код никто не пишет. 90% работы - это общение с клиентами, писание требований, документирование, объяснение клиентам, почему их требования не имеют смысла, где взять готовый продукт, делающий нужное, и прочая и прочая.
Ход мысли не программиста-фанатика, мыслящего категориями "как и на чем писать", а категориямии руководителя-менеджера "зачем писать, какие ресурсы использовать для этого, какая будет прибыль и какие дальнейшие прибыли или убытки это за собой потянет".
1) Язык программирования не должен мешать программированию и не отправлять стричь яка. Т.е. если мне для реализации проекта внезапно оказывается необходимым общаться лично с автором виндового рунтайма хаскеля - извините, в продакшен непригодно.
2) Основная проблема - это не собственно выполнение работы (по моему, если не лезть в реализацию совсем уж новых концепций программирования, типа "а теперь мы сделаем хаскель, на котором можно писать низкоуровневые драйвера", то все мыслимое и немыслимое уже придумано и сделано, достаточно разобраться, склеить и скомпилировать), а заставить себя взяться за эту работу. Если язык при этом лезет под ноги всяким тупизмом, т.е. в 2012 году ВНЕЗАПНО не работает "искаропки" - отправляется в утиль.
Есть только одно неприятное следствие вышеуказанного: если так думать, заниматься "личными" проектами становится крайне затруднительно. Прибыли от них нет, приобретенное умение программировать уже НЕ НУЖНО, сделать что-то действительно новое и полезное - 90% будет не код, а анализ рынка, реклама, общение с коллегами, клиентами, заказчиками, опен-сорсным комьюнити и прочая.
А писать в стол всякое уныние, коего готового 100500 вариантов - нет вообще никаких стимулов.
Последнее время эта тема напрягает, т.к. я привык постоянно заниматься какими-то "интересными проектами", но постепенно требования к ним в силу моего перфекционизма переросли порог "можно сделать в свободное время не напрягаясь".
0) Выбор языка программирования - по сараю. Код никто не пишет. 90% работы - это общение с клиентами, писание требований, документирование, объяснение клиентам, почему их требования не имеют смысла, где взять готовый продукт, делающий нужное, и прочая и прочая.
Ход мысли не программиста-фанатика, мыслящего категориями "как и на чем писать", а категориямии руководителя-менеджера "зачем писать, какие ресурсы использовать для этого, какая будет прибыль и какие дальнейшие прибыли или убытки это за собой потянет".
1) Язык программирования не должен мешать программированию и не отправлять стричь яка. Т.е. если мне для реализации проекта внезапно оказывается необходимым общаться лично с автором виндового рунтайма хаскеля - извините, в продакшен непригодно.
2) Основная проблема - это не собственно выполнение работы (по моему, если не лезть в реализацию совсем уж новых концепций программирования, типа "а теперь мы сделаем хаскель, на котором можно писать низкоуровневые драйвера", то все мыслимое и немыслимое уже придумано и сделано, достаточно разобраться, склеить и скомпилировать), а заставить себя взяться за эту работу. Если язык при этом лезет под ноги всяким тупизмом, т.е. в 2012 году ВНЕЗАПНО не работает "искаропки" - отправляется в утиль.
Есть только одно неприятное следствие вышеуказанного: если так думать, заниматься "личными" проектами становится крайне затруднительно. Прибыли от них нет, приобретенное умение программировать уже НЕ НУЖНО, сделать что-то действительно новое и полезное - 90% будет не код, а анализ рынка, реклама, общение с коллегами, клиентами, заказчиками, опен-сорсным комьюнити и прочая.
А писать в стол всякое уныние, коего готового 100500 вариантов - нет вообще никаких стимулов.
Последнее время эта тема напрягает, т.к. я привык постоянно заниматься какими-то "интересными проектами", но постепенно требования к ним в силу моего перфекционизма переросли порог "можно сделать в свободное время не напрягаясь".
no subject
Для такого хитрого случая, как подземные/подводные передатчики можно сделать релей - на поверхности будет приемник аварийного сигнала и передатчик сигнала на спутники/GSM. Такая система давно применяется в охранных системах - где-то в недрах объекта спрятаны слабые автономные датчики, которые импульсно сигналят на местный "пульт". Сразу включается сирена и вызов оперативных служб.
В вашем случае нужно мониторить не только аварийный сигнал, но и состояние. Можно сделать по той же схеме: защищенные датчики, контроллер и передатчик на объекте - пульт вахтера - интернет/телефон/спутник.
no subject
"В вашем случае нужно мониторить не только аварийный сигнал, но и состояние. Можно сделать по той же схеме: защищенные датчики, контроллер и передатчик на объекте - пульт вахтера - интернет/телефон/спутник."
Была такая идея. Но еще раз, заказчик рассылает свои вентили черт-те куда и вполне может продать 1 штуку. Представляете решение: городить времянку с вахтером, пультом, приёмником, спутниковым терминалом для того, что следить за одним вентилем. Кроме того, вентиль напрочь металлический и в произвольных условиях, то есть внезапно может быть на глубине в 100 метров.
В итоге я просто хотел показать, что при расплывчатых условиях использования можно подписаться на заведомо нереализуемый проект. Ни вы, ни второй собеседник не спросили, сколько собственно стоит сам вентиль, в какую среду и на какую глубину он будет погружен, какие нагрузки должен выдерживать, какое время автономной работы должно обеспечивать устройство и какие предельные температуры. Каждый из этих пунктов легко и непринужденно меняет стоимость проекта на порядок, а сравнение со стоимостью вентиля сразу говорит нам о целесообразности проекта и это именно тот случай, когда клиент не прав, потому что он не заплатит.