Внесу свои 3 копейки. Используем как раз Idea, но проект собираем с помощью maven из которого Idea умеет импортировать проект.
Сначала закоммитили .idea для удобства и вроде бы все шло хорошо, но потом началось веселье: Idea занимается в фоне особой магией, и иногда меняет порядок записей в файлах — регулярно вылезали конфликты на пустом месте. Кроме того, на каждую зависимость из maven в подпапке .idea на лету создается XML-файл и иногда не удаляется при чекауте другого бранча без этой зависимости (см. фоновая магия), для чекаута обратно нужно вручную чистить.
Через несколько недель эта возня всем надоела и .idea отправилась в .gitignore.
P.S. В .gitignore у нас помойка, но пока никто не жалуется.
На древнючем коболе, крутящемся на древнючих мейнфреймах, без системы контроля версий, с тыщами захардкоденных SQL-запросов, и программируют/поддерживают это дело через древнючие терминалы.
А еще лучше — держать свои дллки возле бинарника, а не в %System32%.
Так дополнительно к защите от описанного эксплоита уменьшается риск того, что кто-то в процессе инсталляции чего-нибудь другого заменит дллку на другую версию, с которой прога несовместима вплоть до креша в неопределенный момент времени.
Так задумано, вот что говорит по этому поводу Реймонд Чен:
Back in the old days, programmers were assumed to be smart and hardworking. Windows didn't provide functions for things that programs could already do on their own.
В старые добрые времена предполагалось, что программисты — умны и старательны. Windows не предоставляла функций для того, что программы и сами могут сделать
То есть, если проверку можно написать самому — ее нужно писать самому, а кто не может или не хочет — сам себе злой Буратино.
В его блоге еще много язвительных замечаний и баек в духе «В конце восьмидесятых было принято, что функция должна стараться отработать даже на неверных данных. Это сейчас в таком случае следует немедленно завершить работу программы с воплями и криками». Весьма занимательное чтиво.
Вот здесь одно из пояснений, почему так, а не иначе. Цитата:
"… В общем, получалось, что простой перекомпиляцией тут не обойтись, а поиск и корректная замена множества строковых констант во всех портируемых приложениях обещала если не влететь в копеечку, то сильно затормозить процесс перехода на новую платформу. Основная сложность тут не поменять код, а убедить производителей программного обеспечения поменять код ..."
> есть идея объеденения web сервера и интерпритатора в один «флакон» с возможностью маштабирования на несколько серверов
Для начала, наверное, можно реализовать в виде модуля для апача или нгинкса — а может, так и оставить. Ведь реализация сервера отберет много сил и затруднит перенос на другие платформы. Но предусмотреть масштабируемость сразу в языке — это круто.
> выполнение паралельных вычислений (для увеличения скорости выполнения)
Тоже здорово. Может это удастся совместить с масштабируемостью? Например, параллелить интерпретатор на процессы, общающиеся по TCP/IP. Или, более глобально (т. е. если время будет позволять), обратить взоры к грид-системам: там немало знаний накопилии и шишек набили, а осязаемое применение лично я видел только в IncrediBuild.
А на скорости выполнения не нужно зацикливаться. Через год процессоры станут ядренее и ядернее, а еще через год… Для начала скорость должна быть просто приемлимой, то есть без несуразных тормозов.
> (работа с БД, XML и т. д) вынести в расширения
Гм. Все-таки без БД далеко не уедешь, неплохо бы предусмотреть стандартный слой абстракции для работы с БД, хотя бы какие-нибудь data objects, чтобы с записями в базе работать как с объектами. Это — точно окупится.
Ну, я такого не говорил :) В теории, любой язык можно как интерпретировать, так и компилировать, или и то и другое. Но, конечно, в суровой действительности языки не висят в воздухе — без платформы язык никому не нужен, а плодить платформы тоже мало толку. Вот и прирастают к языку такие свойства, как компилируемость или интерпретируемость.
Плюсы интерпретируемости:
1. Интерпретируемость помогает переносимости — для портирования достаточно реализовать интерпретатор для нужной системы.
2. Интерпретатор писать проще, чем компилятор.
3. Легче ограничить возможности программ (иногда нечего лишний раз процессы запускать) и уменьшить разрушительные последствия разного рода ошибок.
4. Ну, и главное преимущество:
Сначала закоммитили .idea для удобства и вроде бы все шло хорошо, но потом началось веселье: Idea занимается в фоне особой магией, и иногда меняет порядок записей в файлах — регулярно вылезали конфликты на пустом месте. Кроме того, на каждую зависимость из maven в подпапке .idea на лету создается XML-файл и иногда не удаляется при чекауте другого бранча без этой зависимости (см. фоновая магия), для чекаута обратно нужно вручную чистить.
Через несколько недель эта возня всем надоела и .idea отправилась в .gitignore.
P.S. В .gitignore у нас помойка, но пока никто не жалуется.
Тривиальные вещи делают неделями, куча времени уходит на поиски не там поставленой точки — привет, кобол, и сообщения об ошибках покруче, чем в С++!
В итоге поддержка и развитие такой системы встает чуть ли не на порядки дороже написанной, скажем, на Java — начиная уже с поиска специалистов.
Но, как можно догадаться, переписать все заново еще на порядок дороже. Вот и сидят на коболе.
Не шутка.
Так дополнительно к защите от описанного эксплоита уменьшается риск того, что кто-то в процессе инсталляции чего-нибудь другого заменит дллку на другую версию, с которой прога несовместима вплоть до креша в неопределенный момент времени.
Back in the old days, programmers were assumed to be smart and hardworking. Windows didn't provide functions for things that programs could already do on their own.
В старые добрые времена предполагалось, что программисты — умны и старательны. Windows не предоставляла функций для того, что программы и сами могут сделать
То есть, если проверку можно написать самому — ее нужно писать самому
, а кто не может или не хочет — сам себе злой Буратино.В его блоге еще много язвительных замечаний и баек в духе «В конце восьмидесятых было принято, что функция должна стараться отработать даже на неверных данных. Это сейчас в таком случае следует немедленно завершить работу программы с воплями и криками». Весьма занимательное чтиво.
"… В общем, получалось, что простой перекомпиляцией тут не обойтись, а поиск и корректная замена множества строковых констант во всех портируемых приложениях обещала если не влететь в копеечку, то сильно затормозить процесс перехода на новую платформу. Основная сложность тут не поменять код, а убедить производителей программного обеспечения поменять код ..."
А можно ссылку? На сайте Putty есть ссылка сюда rechten.uvt.nl/koops/cryptolaw/, там про запрет SSH ничего не нашел.
Для начала, наверное, можно реализовать в виде модуля для апача или нгинкса — а может, так и оставить. Ведь реализация сервера отберет много сил и затруднит перенос на другие платформы. Но предусмотреть масштабируемость сразу в языке — это круто.
> выполнение паралельных вычислений (для увеличения скорости выполнения)
Тоже здорово. Может это удастся совместить с масштабируемостью? Например, параллелить интерпретатор на процессы, общающиеся по TCP/IP. Или, более глобально (т. е. если время будет позволять), обратить взоры к грид-системам: там немало знаний накопилии и шишек набили, а осязаемое применение лично я видел только в IncrediBuild.
А на скорости выполнения не нужно зацикливаться. Через год процессоры станут ядренее и ядернее, а еще через год… Для начала скорость должна быть просто приемлимой, то есть без несуразных тормозов.
> (работа с БД, XML и т. д) вынести в расширения
Гм. Все-таки без БД далеко не уедешь, неплохо бы предусмотреть стандартный слой абстракции для работы с БД, хотя бы какие-нибудь data objects, чтобы с записями в базе работать как с объектами. Это — точно окупится.
1. Интерпретируемость помогает переносимости — для портирования достаточно реализовать интерпретатор для нужной системы.
2. Интерпретатор писать проще, чем компилятор.
3. Легче ограничить возможности программ (иногда нечего лишний раз процессы запускать) и уменьшить разрушительные последствия разного рода ошибок.
4. Ну, и главное преимущество: