Comments 72
Главная разница — в наличии у программы обширнейшей оболочки, не связанной «содержимым» программы.странная у вас классификация. Если я вместо shell-скрипта напишу небольшую программку на сях без всякой документации, поддержки, инсталлятора и прочего барахла, то вы назовете ее скриптом?
А то, что вы описали (программа + «обвязка») я бы скорее назвал приложением.
P.S. весь пост еще не осилил, много букв
Нет, я же про это написал — я это назову «плохой программой». Скрипт допускает отсутствие документации в силу своей самоочевидности (и самодокументируемости исходным текстом). Если текст вашей программы не может быть тривиально понятен при открытии файла на просмотр, это уже программа. И если она не имеет должного оформления, то это плохая программа.
плохая программа не равно ненужная программа. она тоже имеет право на жизнь.
Ваша классификация хромает, мягко говоря. Я знаю много скриптов которые по сложности и уровню документации конкурируют с любой программой (возьмите любую cms на php)
Единственная разница между программой и скриптом в общепринятых значениях — используемый язык. Если язык компилируемый (с++, pascal), то это программа, если язык интерпретируемый (php,perl) — это скрипт.
Единственная разница между программой и скриптом в общепринятых значениях — используемый язык. Если язык компилируемый (с++, pascal), то это программа, если язык интерпретируемый (php,perl) — это скрипт.
Вы пропустили мимо всё, что я написал. «Чем различается скрипт и программа? Вовсе не используемым языком» — в самом начале.
Разумеется, программа может быть написана на PHP, а скрипт — на C (более того, у меня на старой работе одна из специфичных задач решалась скриптом на си, потому что из си это было удобнее сделать, чем из шелла).
Программа от скрипта отличается:
* Сложным алгоритмом (обширной логикой)
* Сопроводительной документаций
* Широкой областью применимости (относительной универсальностью)
* Подчинению полиси для дистрибьютива/ОС
* Тщательной проверки параметров и предсказуемым поведением в нестандартных ситуациях
Если же код имеет сложный алгоритм, но не имеет сопроводительной документации (и далее по списку) — то это либо плохая программа, либо плохой скрипт.
Скрипт — «код», настолько компактный и логичный, что является самодокументированным.
Насчёт скриптовых языков… С учётом, что процентов 50% минимального дистрибьютива дебиана это программы для интерпретаторов, говорить о том, что «интерпретируемые программы не программы» было бы глупо.
Разумеется, программа может быть написана на PHP, а скрипт — на C (более того, у меня на старой работе одна из специфичных задач решалась скриптом на си, потому что из си это было удобнее сделать, чем из шелла).
Программа от скрипта отличается:
* Сложным алгоритмом (обширной логикой)
* Сопроводительной документаций
* Широкой областью применимости (относительной универсальностью)
* Подчинению полиси для дистрибьютива/ОС
* Тщательной проверки параметров и предсказуемым поведением в нестандартных ситуациях
Если же код имеет сложный алгоритм, но не имеет сопроводительной документации (и далее по списку) — то это либо плохая программа, либо плохой скрипт.
Скрипт — «код», настолько компактный и логичный, что является самодокументированным.
Насчёт скриптовых языков… С учётом, что процентов 50% минимального дистрибьютива дебиана это программы для интерпретаторов, говорить о том, что «интерпретируемые программы не программы» было бы глупо.
Притянуто за уши. Есть следующая общепринятая терминология, все что интерпретируемое — скрипты, все что скомпилировано — программы.
При чем здесь их сложность и функционал?
Вы зачем то пытаетесь навязать нам самопальную классификацию и добавить хаоса. Не надо!
ИМХО
При чем здесь их сложность и функционал?
Вы зачем то пытаетесь навязать нам самопальную классификацию и добавить хаоса. Не надо!
ИМХО
Во-первых, грубое деление на «скомпилировано/интерпретируемо» несколько устарело. например, байт-код — это интерпретируемое или компилируемое? А JIT-компиляция? А байткод питона?
Во-вторых (и это важно) я не собираюсь вводить «самопальную классификацию», я говорю про реальное состояние дел в хозяйстве системного администратора. Называть скриптом, например, deluge у меня язык не повернётся (хоть он на питоне и написан). Так же у меня не повернётся язык называть приложением (программой) цикл на Си, который выводит список файлов с заданным атрибутом в файловой системе.
Не обижайтесь, но вы почему-то решили, что я собираюсь рассказывать людям что есть интерпретируемые языки программирования, а потом высказываете претензию, что этот рассказ неправильный.
Во-вторых (и это важно) я не собираюсь вводить «самопальную классификацию», я говорю про реальное состояние дел в хозяйстве системного администратора. Называть скриптом, например, deluge у меня язык не повернётся (хоть он на питоне и написан). Так же у меня не повернётся язык называть приложением (программой) цикл на Си, который выводит список файлов с заданным атрибутом в файловой системе.
Не обижайтесь, но вы почему-то решили, что я собираюсь рассказывать людям что есть интерпретируемые языки программирования, а потом высказываете претензию, что этот рассказ неправильный.
Да какие обиды, бросьте! В споре рождается истина!
Дело в том, что вы подменяете общепринятое понятие «скрипт — интерпретируемая программа» на «скрипт — программа на колене». Найдите другие слова и не вносите смуту.
Дело в том, что вы подменяете общепринятое понятие «скрипт — интерпретируемая программа» на «скрипт — программа на колене». Найдите другие слова и не вносите смуту.
Считайте, что слово-омоним. Как, например, приложение. Ethernet — это «приложение» (так же как телефония) с точки зрения СКС. Однако, в компьютерах приложением называют что-то совсем другое, чем электрический стандарт кодирования битов.
Примерно так же и тут. Да, у программистов своё представление о том, что есть скриптовый язык, а что нет. У администраторов — своё. Скриптами называют не программу на скриптовом языке программирования, а костыль для реализиации локальной задачи. Вряд ли кто-то в здравом создании назовёт конфигурацию 1ц бухгалтерии «скриптом бухгалтерского учёта».
Примерно так же и тут. Да, у программистов своё представление о том, что есть скриптовый язык, а что нет. У администраторов — своё. Скриптами называют не программу на скриптовом языке программирования, а костыль для реализиации локальной задачи. Вряд ли кто-то в здравом создании назовёт конфигурацию 1ц бухгалтерии «скриптом бухгалтерского учёта».
>Если же у вас цикл, в котором по проверке условия запускается цикл
о боже, я не написал не одного скрипта…
>следует начать с поиска программы
а через 2 часа поисков и находки, понимаешь что это не то что тебе надо, нет логов в нужной форме, нельзя скормить нужные параметры и все равно пишешь «скрипт»(программу)
> "_ЗДЕСЬ_И_СЕЙЧАС_", "_ТАМ_И_ВСЕГДА_"
как я могу использовать программу, если я не уверен что мне может понадобиться от неё завтра? поюзать её пару дней, а потом все же написать «скрипт»(программу)?
о боже, я не написал не одного скрипта…
>следует начать с поиска программы
а через 2 часа поисков и находки, понимаешь что это не то что тебе надо, нет логов в нужной форме, нельзя скормить нужные параметры и все равно пишешь «скрипт»(программу)
> "_ЗДЕСЬ_И_СЕЙЧАС_", "_ТАМ_И_ВСЕГДА_"
как я могу использовать программу, если я не уверен что мне может понадобиться от неё завтра? поюзать её пару дней, а потом все же написать «скрипт»(программу)?
Поиск нужного приложения для реализации задачи может занимать куда больше, чем пара часов. Возможно, на это потребуется месяц, а то и больше. Я говорю про продакт системы, в пределах «мне нужно читать RSS и писать это в мой mp3-плеер» можно делать что хочешь. Если же система вам не принадлежит (aka продакт-система организации), то следует учитывать наличие тех, кто придёт вам на смену.
Задача «не может принять в нужной форме» как раз решается скриптом в одну строчку (с использованием awk). И это вполне достойная задача скрипта — подготовить инфраструктуру для запуска приложения или связать два приложения между друг другом.
Я не знаю, как вы можете использовать программы. Я обычно примерно себе представляю ТЗ для неё и сроки (область) применения.
Задача «не может принять в нужной форме» как раз решается скриптом в одну строчку (с использованием awk). И это вполне достойная задача скрипта — подготовить инфраструктуру для запуска приложения или связать два приложения между друг другом.
Я не знаю, как вы можете использовать программы. Я обычно примерно себе представляю ТЗ для неё и сроки (область) применения.
>Отладив скрипт вы получите лишь костыль, прочность и долговечностью которого не знает даже автор.
на моей практике рабочих скриптов намного больше чем программ. некоторые работают годами и все хорошо.
по поводу инструкций — если ты пишешь для "_ЗДЕСЬ_И_СЕЙЧАС_" они как бы и не нужны. Тебе нужно в кротчайшие сроки достигнуть цели и время на поиски программ, их изучения, подгонку совершенно нет. К тому же нужный софт может быть платным — а скрипт продукт твоей работы и за него платить тебя никто не заставит.
+этика комментирования строчек кода, чтобы те кто тебя заменят смогли понять что к чему.
p.s. может мы с вами понимаем разные вещи под словом «скрипт»?
на моей практике рабочих скриптов намного больше чем программ. некоторые работают годами и все хорошо.
по поводу инструкций — если ты пишешь для "_ЗДЕСЬ_И_СЕЙЧАС_" они как бы и не нужны. Тебе нужно в кротчайшие сроки достигнуть цели и время на поиски программ, их изучения, подгонку совершенно нет. К тому же нужный софт может быть платным — а скрипт продукт твоей работы и за него платить тебя никто не заставит.
+этика комментирования строчек кода, чтобы те кто тебя заменят смогли понять что к чему.
p.s. может мы с вами понимаем разные вещи под словом «скрипт»?
… скрипты работают годами где? В том месте, где их написали и оставили? А если сеть перевести на DHCP? А если поменять платформу с *x на *y?
Ситуаций, когда нужный софт был бы платным, его функционал можно было в разумное время реализовать скриптом, и у него бы не было бесплатных аналогов — я в своей жизни не видел.
Ситуаций, когда нужный софт был бы платным, его функционал можно было в разумное время реализовать скриптом, и у него бы не было бесплатных аналогов — я в своей жизни не видел.
… программы работают годами где? В том месте, где их написали и оставили? А если перевести на DHCP? А если поменять платформу с *x на *y?
извините, не удержался…
initscripts подчиняется списку
* Сложным алгоритмом (обширной логикой)
* Сопроводительной документаций
* Широкой областью применимости (относительной универсальностью)
* Подчинению полиси для дистрибьютива/ОС
* Тщательной проверки параметров и предсказуемым поведением в нестандартных ситуациях
но это явный скрипт(куча скриптов) с моей точки зрения( по «математико-программистким представлениям»), разьясните почему этот скрипт будет по вашему списку программой? я что-то не допонял видимо
извините, не удержался…
initscripts подчиняется списку
* Сложным алгоритмом (обширной логикой)
* Сопроводительной документаций
* Широкой областью применимости (относительной универсальностью)
* Подчинению полиси для дистрибьютива/ОС
* Тщательной проверки параметров и предсказуемым поведением в нестандартных ситуациях
но это явный скрипт(куча скриптов) с моей точки зрения( по «математико-программистким представлениям»), разьясните почему этот скрипт будет по вашему списку программой? я что-то не допонял видимо
ах да, и разницу между плохой програмой и плохим скриптом я тоже не понял =)
Нет, это не скрипт, это программа на скриптовом языке. Отличается от скрипта она именно перечисленным.
>А если сеть перевести на DHCP? А если поменять платформу с *x на *y?
ну это уже скорее подходит под категорию "_ТАМ_И_ВСЕГДА_"
>Ситуаций, когда нужный софт был бы платным, его функционал можно было в разум…
вот опять вы про тоже. я пытаюсь сказать что скрипты выполняют несложную, рутинную работу. Позволяют автоматизировать некоторые процессы — не такие глобальные. например бекапы(зачем покупать софт если можно написать шелл скрипт?), парсинг-фильтрация логов, мониторинг нужной службы с оповещением на телефон\аськуджаббер\мыло.
Конечно можно воспользоваться программой которая будет весить в разы больше и если ты найдешь в ней баг под конкретную ситуацию тебе придется ждать заплатки(если купил то там сапорт поможет), если опен-сурс — то знаний еще больше понадобится.
я с вами согласен в плане скрипт-"_ЗДЕСЬ_И_СЕЙЧАС_", софт-"_ТАМ_И_ВСЕГДА_". порой сроки поджимают. И для начала нужно написать скрипт, и пока он будет работать задуматься «а нужна ли программа?» или заняться её поиском.
ну это уже скорее подходит под категорию "_ТАМ_И_ВСЕГДА_"
>Ситуаций, когда нужный софт был бы платным, его функционал можно было в разум…
вот опять вы про тоже. я пытаюсь сказать что скрипты выполняют несложную, рутинную работу. Позволяют автоматизировать некоторые процессы — не такие глобальные. например бекапы(зачем покупать софт если можно написать шелл скрипт?), парсинг-фильтрация логов, мониторинг нужной службы с оповещением на телефон\
Конечно можно воспользоваться программой которая будет весить в разы больше и если ты найдешь в ней баг под конкретную ситуацию тебе придется ждать заплатки(если купил то там сапорт поможет), если опен-сурс — то знаний еще больше понадобится.
я с вами согласен в плане скрипт-"_ЗДЕСЬ_И_СЕЙЧАС_", софт-"_ТАМ_И_ВСЕГДА_". порой сроки поджимают. И для начала нужно написать скрипт, и пока он будет работать задуматься «а нужна ли программа?» или заняться её поиском.
комментарий к ветке выше.
Именно с прицелом на «оповещалку» я и писал это. Если у вас скрипт реализует нетривиальную логику (проверить, что SMTP работает, если не работает, то оповестить админа альтернативным методом), то это ПЛОХОЙ скрипт. Даже если он работает. Потому что следующий админ будет вынужден либо изучать персонально ваши скрипты, либо писать свои. И то и то, плохо.
Правильный выход — поднять nagios и настроить отсылку оповещений оттуда. Да, это займёт времени больше, чем скрипт для мониторинга конкретного сервиса, однако, это будет общее решение для проблемы «мониторить всё».
Правильный выход — поднять nagios и настроить отсылку оповещений оттуда. Да, это займёт времени больше, чем скрипт для мониторинга конкретного сервиса, однако, это будет общее решение для проблемы «мониторить всё».
а если новый не знает что такое нагиос? он будет изучать что это и как это работает. потом посмотрит как вы это настроили, все удалит и настроит по своему-а если ему будет лень, то напишет скрипт.
у вас в профиле написано «ненавижу Microsoft», это же не значит что для окон скриптов не пишут.
Нагиос насколько помню юникс-подобных ос, бывают админы которые с юниксами на вы и они не держат серваков на онных. Или это уже не системные администраторы?
у вас в профиле написано «ненавижу Microsoft», это же не значит что для окон скриптов не пишут.
Нагиос насколько помню юникс-подобных ос, бывают админы которые с юниксами на вы и они не держат серваков на онных. Или это уже не системные администраторы?
Я про это и говорю. Вместо того, чтобы с увлечением писать скрипт, с которым вашему последователю придётся разбираться, нужно напрячься и поставить нагиос (или другую систему мониторинга), для которой чужие дяди УЖЕ написали документацию.
Если вы пишите скрипт, будьте добры написать к нему документацию, хотя бы в 1/10 от документации нагиоса.
Мысль статьи простая: пишите код — он должен быть либо очевиден с первого взгляда, либо иметь документацию. Первое называется скрипт, второе — программа. Статья посвящена объяснению того, что не нужно писать программы с уровнем документированности скрипта.
nagios прекрасно мониторит виндовые сервера; у майкрософта, насколько я знаю, есть system manager, который делает что-то подобное.
Если прийдёт новый админ и увидит, что «тут стоит нагиос» и «тут какая-то куча скриптов», то какова вероятность а) что он прочитает про нагиос б) что он изучит скрипты без документации?
Если вы пишите скрипт, будьте добры написать к нему документацию, хотя бы в 1/10 от документации нагиоса.
Мысль статьи простая: пишите код — он должен быть либо очевиден с первого взгляда, либо иметь документацию. Первое называется скрипт, второе — программа. Статья посвящена объяснению того, что не нужно писать программы с уровнем документированности скрипта.
nagios прекрасно мониторит виндовые сервера; у майкрософта, насколько я знаю, есть system manager, который делает что-то подобное.
Если прийдёт новый админ и увидит, что «тут стоит нагиос» и «тут какая-то куча скриптов», то какова вероятность а) что он прочитает про нагиос б) что он изучит скрипты без документации?
эх мечты мечты… я про то, что когда приходишь на новое место и там все прям для тебя. в столе папочка с документациями по структуре предприятия, где какой сервак и какие крутятся на нем сервисы. на каком из серверов в кроне висит скрипт для бекапов и что он бекапит. какие бывают частые глюки с их решениями(я думаю у каждого админа есть такие). Отдельно лежит папочка с лицензиями на весь конторский софт. а то иногда приходишь, а от прошлого админа и след простыл… и сидишь отлавливаешь все и разгребаешь. и тоже ничего не документируешь…
Стопочки документации нет. Есть стопочка статей в локальной вики.
Правилом хорошего тона является передача дел при уходе. Мой предшественник этого толком не сделал, пришлось и файло на его компе восстанавливать, и пароли сбрасывать. Было неприятно.
Я в течении двух положенных недель до увольнения честно писал простыни о структуре баз данных, о возникающих проблемах, и т.д. Но до этого в отделе хорошим правилом для уходящих в отпуск стало подобное изложение основных вопросов, с которыми придется столкнуться резервному сотруднику.
Начальник у нас был хороший, требовал подобных действий до ухода в отпуск. И коллеги с основными заморочками по подобному корану справятся, и тебя с пляжа телефонным звонком не выдернут.
Я в течении двух положенных недель до увольнения честно писал простыни о структуре баз данных, о возникающих проблемах, и т.д. Но до этого в отделе хорошим правилом для уходящих в отпуск стало подобное изложение основных вопросов, с которыми придется столкнуться резервному сотруднику.
Начальник у нас был хороший, требовал подобных действий до ухода в отпуск. И коллеги с основными заморочками по подобному корану справятся, и тебя с пляжа телефонным звонком не выдернут.
А я при уходе ничего не писал, кроме конверта с паролями. Потому что всё это было написано в течение рабочего времени, а не судорожно «в последние две недели».
Вы знаете, «судорожно» ничего не писалось. У нас было краткое описание таблиц и полей, возможность просмотра структуры базы через бормановский SQL Explorer на резервной базе, и некоторые куски исходников серверной части, которые буквально выпрашивались у головного офиса. На раскрутку одной подсистемы у меня ушло больше года, и все эти знания — схему данных, описание основных нештатных ситуаций, примерный список действий пользователей при проведении базовых операций, я передал коллеге. К счастью, он промаялся с этим наследием всего лишь месяц.
А Вам повезло больше, даже немного завидую. Но опять же, я не был разработчиком, а был в техподдержке убожества, созданного Teleform.Ru.
А Вам повезло больше, даже немного завидую. Но опять же, я не был разработчиком, а был в техподдержке убожества, созданного Teleform.Ru.
Прочитал, в целом идеи в статье изложены верные, хотя я бы не стал так критично относится к роли скриптов в администрировании. Просто важно всегда четко ставить цель и применять те инструменты, которые в данных условиях будут наиболее эффективны.
Немного критики.
Как насчет хорошей верстки? Читать и воспринимать такую «простыню» текста очень сложно. Хорошая статья требует не только хорошей идеи для нее, но и хорошего воплощения ее, идеи, в жизнь. Кстати, это касается почти любой идеи.
Пока это больше похоже на поток мыслей.
Немного критики.
Как насчет хорошей верстки? Читать и воспринимать такую «простыню» текста очень сложно. Хорошая статья требует не только хорошей идеи для нее, но и хорошего воплощения ее, идеи, в жизнь. Кстати, это касается почти любой идеи.
Пока это больше похоже на поток мыслей.
Ух, здорово. Немного категорично как-то, это все же ваше мнение, но в целом неплохо. Со многим согласен.
Являются ли рецепты шефа, puppet или cfengine недопрограммами или все же скриптами.
cfengine являются программами: www.cfengine.org/pages/documentation
Остальное не видел, не знаю.
Повторю: разница между скриптом и программой не в том, как они написаны, а в том, как они сопровождаются.
Остальное не видел, не знаю.
Повторю: разница между скриптом и программой не в том, как они написаны, а в том, как они сопровождаются.
Согласен. Были случае когда хотелось доработать ряд функций к уже рабочему скрипту, обычно это было просто в пустую потраченное время.
Чем изобретать велосипеды проще поискать уже готовое решение и адаптировать его под себя тем же скриптом.
Не нужно примитивному скрипту для бэкапов уметь делать дифференциальные бэкапы, это можно сделать уже готовой системой резервирования.
Отличная статья.
Чем изобретать велосипеды проще поискать уже готовое решение и адаптировать его под себя тем же скриптом.
Не нужно примитивному скрипту для бэкапов уметь делать дифференциальные бэкапы, это можно сделать уже готовой системой резервирования.
Отличная статья.
Правильно будет говорить не «проще», а «правильнее». Потому что проще всё-таки написать самому. Но цена сопровождения и развития этого решения окажется много больше, чем сопровождения существующего решения.
>Не нужно примитивному скрипту для бэкапов уметь делать дифференциальные бэкапы, это можно сделать уже готовой системой резервирования.
пардон, на какой системе нужно писать скрипт для дифференциальных бэкапов?
пардон, на какой системе нужно писать скрипт для дифференциальных бэкапов?
Поначалу подумал, что это перевод, решил дочитать до конца… Ан нет, не перевод.
>признак крайней куцести рабочей среды
Аффтар, а Вам не доводилось работать в техподдержке конторы, где любые средства разработки программ запрещены? И где только скрипты являются выходом из многих и многих ситуаций?
>Если у вас скрипт реализует нетривиальную логику (проверить, что SMTP работает, если не работает, то оповестить админа альтернативным методом), то это ПЛОХОЙ скрипт.
Да с куя ли?
>признак крайней куцести рабочей среды
Аффтар, а Вам не доводилось работать в техподдержке конторы, где любые средства разработки программ запрещены? И где только скрипты являются выходом из многих и многих ситуаций?
>Если у вас скрипт реализует нетривиальную логику (проверить, что SMTP работает, если не работает, то оповестить админа альтернативным методом), то это ПЛОХОЙ скрипт.
Да с куя ли?
Нет, не приходилось. Более того, я ушёл из компании, где я был рутом в компанию, где от меня до рута человека три по иерархии. И там, и там все технические специалисты сами отвечали за работоспособность машины. Точнее, был один… м… не очень квалифицированный — «веб дизайнер», его машину обслуживали мы (ит-отдел) и у него прав администратора не было. В остальных — хочешь свободы — держи, если можешь удержать.
И я с трудом себе представляю компанию, в которой системный администратор не имеет права использовать то, что является удобным/нужным.
Кроме того, речь идёт не о том, «на чём писать», а о том, что скрипт и программа различаются не кодом, а административным подходом.
Насчёт «да с куя ли» — я, вроде, простыню уже написал.
И я с трудом себе представляю компанию, в которой системный администратор не имеет права использовать то, что является удобным/нужным.
Кроме того, речь идёт не о том, «на чём писать», а о том, что скрипт и программа различаются не кодом, а административным подходом.
Насчёт «да с куя ли» — я, вроде, простыню уже написал.
>И я с трудом себе представляю компанию, в которой системный администратор не имеет права использовать то, что является удобным/нужным.
а я в такой компании проработал семь лет. Пересечение множеств «Сисадмин, админ серверов, админ ЛВС, админ ПО, разработчик» дает пустое подмножество. Кроме того, любая программа, которая написана айтишником, должна пройти кучу тестов, везя за собой ворох документации, и не факт, что будет принята в эксплуатацию. Конечно, можно использовать свои разработки неофициально, но если программа не отработает, как надо, то придется держать ответ самому.
>Насчёт «да с куя ли» — я, вроде, простыню уже написал.
ну здесь опять же… Если интересует, я могу в ЛС или в почте описать Вам ситуацию с внедрением стороннего ПО. За исключением ссылок на пункты инструкций, номера которых за год после ухода порядком подзабыл:)
>а о том, что скрипт и программа различаются не кодом, а административным подходом
с этим я не согласен, но к аргументированному обсуждению пока не готов, увы.
а я в такой компании проработал семь лет. Пересечение множеств «Сисадмин, админ серверов, админ ЛВС, админ ПО, разработчик» дает пустое подмножество. Кроме того, любая программа, которая написана айтишником, должна пройти кучу тестов, везя за собой ворох документации, и не факт, что будет принята в эксплуатацию. Конечно, можно использовать свои разработки неофициально, но если программа не отработает, как надо, то придется держать ответ самому.
>Насчёт «да с куя ли» — я, вроде, простыню уже написал.
ну здесь опять же… Если интересует, я могу в ЛС или в почте описать Вам ситуацию с внедрением стороннего ПО. За исключением ссылок на пункты инструкций, номера которых за год после ухода порядком подзабыл:)
>а о том, что скрипт и программа различаются не кодом, а административным подходом
с этим я не согласен, но к аргументированному обсуждению пока не готов, увы.
Ну… Я могу сказать только одно: если требования являются необоснованными (например, как в одной компании, в которой, я, к счастью, не работал, где админу запрещали в шариться в интернете (!)), то сотрудник должен либо обосновать свои требования, либо принять политику компании. Ситуация, когда «скрипты можно, а программы нельзя» есть фарс и бред, потому что разницу между ними я изложил чуть выше: программа более документирована чем скрипт.
Писать «свою программу» дорого. Очень. Потому я и говорю, что не нужно поддаваться приятному соблазну сделать самому, и надо презнемочь себя и изучить чужое. Потому что чужое, с большой вероятностью, решило множество проблем и имеет наработанную базу. А своё имеет только голый энтузиазм и веру, что получится лучше, чем у всего белого света.
Писать «свою программу» дорого. Очень. Потому я и говорю, что не нужно поддаваться приятному соблазну сделать самому, и надо презнемочь себя и изучить чужое. Потому что чужое, с большой вероятностью, решило множество проблем и имеет наработанную базу. А своё имеет только голый энтузиазм и веру, что получится лучше, чем у всего белого света.
>Ситуация, когда «скрипты можно, а программы нельзя» есть фарс и бред,
но она есть, увы. WSH является встроенным средством Windows, а вот программа, и ее средства разработки — нет.
>программа более документирована чем скрипт.
я просто не вижу разницы в документации — подробные комментарии в скрипте, руководство по кастрюле для пользователей, с подробным описанием и скриншотами, контактные данные техподдержки и т.д. — в чем отличие от программ?
>Потому я и говорю, что не нужно поддаваться приятному соблазну сделать самому, и надо презнемочь себя и изучить чужое.
Да, я согласен, что не стоит самому писать проверку md5 и другие распространенные проверенные алгоритмы. А вот «голый энтузиазм и веру, что получится лучше, чем у всего белого света» было, и получалось не хуже, чем у коллег из других городов, каждый из которых изобретал нечто свое.
Да и написание скриптов порой не исключает изучения чужих наработок, для меня не в плане идей или конкретной реализации, а в плане технических вопросов.
но она есть, увы. WSH является встроенным средством Windows, а вот программа, и ее средства разработки — нет.
>программа более документирована чем скрипт.
я просто не вижу разницы в документации — подробные комментарии в скрипте, руководство по кастрюле для пользователей, с подробным описанием и скриншотами, контактные данные техподдержки и т.д. — в чем отличие от программ?
>Потому я и говорю, что не нужно поддаваться приятному соблазну сделать самому, и надо презнемочь себя и изучить чужое.
Да, я согласен, что не стоит самому писать проверку md5 и другие распространенные проверенные алгоритмы. А вот «голый энтузиазм и веру, что получится лучше, чем у всего белого света» было, и получалось не хуже, чем у коллег из других городов, каждый из которых изобретал нечто свое.
Да и написание скриптов порой не исключает изучения чужих наработок, для меня не в плане идей или конкретной реализации, а в плане технических вопросов.
Никакие, самые подробные комментарии в коде, не заменят документацию по программе. Скрипту — да, до определённого момента мелкое «трудное» место можно объяснить.
Но если у нас появляется сложная часть, завязанная на логику других программ, то она требует очень подробного описания. Не описания «как работает скрипт», а описания «что он делает». И не на уровне «регистрирует обработчик в WMI-репозитории и по получении сигнала изменяет атрибуты snmp», а объяснение «к чему тут вообще WMI, для чего нужно это транслировать в SNMP руками и что есть snmp-комьюнити».
Относительно «получалось не хуже чем у коллег»… Не хуже. Да. Но если бы на этом месте была продуманная система, то, наверняка, было бы лучше.
Я это говорю по нескольким годам возни, как с самописными скриптами, так и с централизованными системами. Сделать самописный скрипт всегда приятнее. Централизованная система всегда надёжнее, особенно в условиях миграции/расширения/изменения.
Но если у нас появляется сложная часть, завязанная на логику других программ, то она требует очень подробного описания. Не описания «как работает скрипт», а описания «что он делает». И не на уровне «регистрирует обработчик в WMI-репозитории и по получении сигнала изменяет атрибуты snmp», а объяснение «к чему тут вообще WMI, для чего нужно это транслировать в SNMP руками и что есть snmp-комьюнити».
Относительно «получалось не хуже чем у коллег»… Не хуже. Да. Но если бы на этом месте была продуманная система, то, наверняка, было бы лучше.
Я это говорю по нескольким годам возни, как с самописными скриптами, так и с централизованными системами. Сделать самописный скрипт всегда приятнее. Централизованная система всегда надёжнее, особенно в условиях миграции/расширения/изменения.
>Да. Но если бы на этом месте была продуманная система, то, наверняка, было бы лучше.
ненавижу «бы». Нет этой системы, и не будет. Поэтому обменивались и по почте, и обсуждали по телефону, что и как делается.
>Не описания «как работает скрипт», а описания «что он делает».
т.е. программа в этом случае выглядит выгоднее? Не вижу разницы, честно.
>Централизованная система всегда надёжнее, особенно в условиях миграции/расширения/изменения.
не всегда. Киньте в ЛС адрес почты, я Вам распишу конкретные ситуации.
ненавижу «бы». Нет этой системы, и не будет. Поэтому обменивались и по почте, и обсуждали по телефону, что и как делается.
>Не описания «как работает скрипт», а описания «что он делает».
т.е. программа в этом случае выглядит выгоднее? Не вижу разницы, честно.
>Централизованная система всегда надёжнее, особенно в условиях миграции/расширения/изменения.
не всегда. Киньте в ЛС адрес почты, я Вам распишу конкретные ситуации.
У вас именно — не будет. Если вы уверены, что вы всю жизнь будете эту систему поддерживать. У меня, например, три десятка скриптов заменилось одним нагиосом, и работает оно куда более красиво с точки зрения архитектуры, и мониторит оно куда больше.
>У вас именно — не будет.
Уже не будет, это верно, ибо я покинул ту контору. Но если вспомнить, сколько времени понадобилось бы на внедрение нагиос или чего-то еще, то лучше обойтись тремя десятками скриптов.
Почему Вы делаете акцент на мониторинге? Оно, конечно важно, но есть у скриптов и другие применения.
Уже не будет, это верно, ибо я покинул ту контору. Но если вспомнить, сколько времени понадобилось бы на внедрение нагиос или чего-то еще, то лучше обойтись тремя десятками скриптов.
Почему Вы делаете акцент на мониторинге? Оно, конечно важно, но есть у скриптов и другие применения.
Внедрение нагиоса с изучением как он работает — меньше недели. Установка агентов — от двух минут до 15 на сервер в зависимости от платформы и скорости работы.
Мониторинг я считаю существенным примером, потому что он (будучи сделан как набор скриптов) для каждого сервера представляет собой зоопарк из 5-15 шт (температура, состояние дисков, фильтрация эвент-лога на виндах, загрузка диска/процессора/памяти, доступность всех нужных сервисов....), что помноженное на какое-то количество серверов приводит нас к несчётному (по пальцам) их количеству.
На скриптах может делаться много что (да хоть весь свой собственный init), но чем скриптов больше, тем менее понятной становится система.
Мониторинг я считаю существенным примером, потому что он (будучи сделан как набор скриптов) для каждого сервера представляет собой зоопарк из 5-15 шт (температура, состояние дисков, фильтрация эвент-лога на виндах, загрузка диска/процессора/памяти, доступность всех нужных сервисов....), что помноженное на какое-то количество серверов приводит нас к несчётному (по пальцам) их количеству.
На скриптах может делаться много что (да хоть весь свой собственный init), но чем скриптов больше, тем менее понятной становится система.
>Внедрение нагиоса с изучением как он работает — меньше недели.
плюс переписка с головной конторой о необходимости внедрения, тестирование, попытки доказать, что мы не тупее паровоза...waste of time, короче, о чем я и написал выше.
>но чем скриптов больше, тем менее понятной становится система.
один скрипт, в котором собраны все необходимые задачи, с разделением по времени. В скрипте расписаны все составляющие в комментариях. Ничем не хуже, я думаю.
плюс переписка с головной конторой о необходимости внедрения, тестирование, попытки доказать, что мы не тупее паровоза...waste of time, короче, о чем я и написал выше.
>но чем скриптов больше, тем менее понятной становится система.
один скрипт, в котором собраны все необходимые задачи, с разделением по времени. В скрипте расписаны все составляющие в комментариях. Ничем не хуже, я думаю.
Вот вы написали, чем отличаются скрипт и программа в вашем понимании. И это не теория правильных скриптов, а теория правильных скриптов в вашем понимании. Вы имеете на это полное право. Вот вы показали статью нам, на то тоже имеете полное право. Но не нужно всех несогласных с вашей теорией, которая отличается от общепринятой классификации, тыкать носом и учить, как правильно.
А еще в языке bash скрипт надо начинать с trap onerror ERR, чтобы хоть как-то имитировать систему обработки исключений.
А еще инвалиды, которые пишут bash скрипты часто не умеют нормально обрабатывать пробелы и кавычки в именах файлов, этим грешат OpenSource рахработчики, какие-то компиляторы например не могут установиться в папку с пробелом в имени (Program Files например :) )
Ну а еще у bash невозмодный синтаксис (если надо учитывать кавычки и пробелы), и писать на нем что-то можно только под страхом смерти. И дурная идея с системой подстановок.
Ну а еще у bash невозмодный синтаксис (если надо учитывать кавычки и пробелы), и писать на нем что-то можно только под страхом смерти. И дурная идея с системой подстановок.
Очень интересная статья. А если приложить этот принцип к вёрстке, то получается, что современный html-код — это программа, исполняемая браузером.
напомнило, на одном из форумов гражданин спросил «как бы мне по фтп скачать сразу всё вместе с вложенными каталогами?», 10+ страниц обсуждений с демонстрацией шеловых скриптов, которые под конец уже почти не глючили…
обсуждение резко остановилось после комментария: «ребята, а вы про wget слышали?»
обсуждение резко остановилось после комментария: «ребята, а вы про wget слышали?»
Автор, получите заслуженное «спасибо, кэп». Объяснили диким туземцам, что программа — это программа, а скрипт — это набор команд для выполнения конкретной прикладной задачи. Молодец.
script даже переводится как сценарий и уже из этого все понятно.
Можно было вот это написать и закончить статью, смысл был бы примерно тот же, но люди время не тратили бы.
script даже переводится как сценарий и уже из этого все понятно.
Грань, в которой заканчивается скрипт найти сложно.
Можно было вот это написать и закончить статью, смысл был бы примерно тот же, но люди время не тратили бы.
Позвольте не согласиться с Вашей классификацией скриптов и программ. Дело не в документации и не в интеграции и поддержке и даже не в сложном алгоритме. Эти качества отличают лишь хорошую программу от плохой, и то не всегда.
Вот и все. Это из википедии.
Скри́птовый язы́к (англ. scripting language, в русскоязычной литературе принято название язык сценариев) — язык программирования, разработанный для записи «сценариев», последовательностей операций, которые пользователь может выполнять на компьютере.
Вот и все. Это из википедии.
UFO just landed and posted this here
Вот я выше выразил то же самое, только в более критичной форме, и схлопотал минуса.
Автор навязывает свое мнение, временами в категоричной форме (аж с капслоком), забывая вежливо указывать, что это только лишь его видение ситуации.
Т.е. в среде *unix все выполнение чего-то после выполнения предыдущих действий недопустимо? Например, поднятие туннельного интерфейса после поднятия беспроводного и все в таком духе?
Такое ощущение, что чей-то кривой «скопипастенный» недокументированный" скрипт со «сложной логикой» ему что-то сломал, и все вокруг неправы и должны быть адски заминусованы в случае несогласия.
Автор навязывает свое мнение, временами в категоричной форме (аж с капслоком), забывая вежливо указывать, что это только лишь его видение ситуации.
Скрипты же НЕ ДОЛЖНЫ ЗАВИСЕТЬ ДРУГ ОТ ДРУГА. Ситуация, когда скрипт зависит от сервисов другого скрипта, который зависит от третьего — ненормальная.
Т.е. в среде *unix все выполнение чего-то после выполнения предыдущих действий недопустимо? Например, поднятие туннельного интерфейса после поднятия беспроводного и все в таком духе?
Такое ощущение, что чей-то кривой «скопипастенный» недокументированный" скрипт со «сложной логикой» ему что-то сломал, и все вокруг неправы и должны быть адски заминусованы в случае несогласия.
Я в своих постах, кроме мата, нигде минуса не ставлю, так что извините.
А в «среде юникс» (если мы про адекватный дистрибьютив, а не про slackware way) программы на интерпретируемых языках вполне себе используются. Как программы. А вот если кто-то пишет свою обвязку, которая вместо вызова N программ реализует их функционал самостоятельно — это плохо. Потому что у программ документация есть, а «самостоятельные реализации» обычно её не имеют.
А в «среде юникс» (если мы про адекватный дистрибьютив, а не про slackware way) программы на интерпретируемых языках вполне себе используются. Как программы. А вот если кто-то пишет свою обвязку, которая вместо вызова N программ реализует их функционал самостоятельно — это плохо. Потому что у программ документация есть, а «самостоятельные реализации» обычно её не имеют.
Т.е. делюга, или там, медиавики — это такой «сценарий», выполняемый пользователем? хм…
Судя по логике автора и его комментариям, предлогаю переименовать пост в «Теория правильных костылей для реализиации локальных задач».
Так он понимает слово — скрипт
Так он понимает слово — скрипт
При достаточно простом тексте скрипта он не является костылём, а является штатным средством в работе.
Это с ваших слов.
Скриптами называют не программу на скриптовом языке программирования, а костыль для реализиации локальной задачи. Вряд ли кто-то в здравом создании назовёт конфигурацию 1ц бухгалтерии «скриптом бухгалтерского учёта».
пост совершенно бестолковый и начемный. не содержит в себе никакой смысловой нагрузки, кроме глупостей.
Пост из разряда «еще один все понял».
Если вы администрируете какие-либо сложные системы, а не просто почтовый/веб сервер компании — то «скриптами» в вашем понимании обойтись сложно.
И еще у меня есть ощущение, что вы не совсем в «теме», а оперируете только академичискими знаниями.
Если вы администрируете какие-либо сложные системы, а не просто почтовый/веб сервер компании — то «скриптами» в вашем понимании обойтись сложно.
И еще у меня есть ощущение, что вы не совсем в «теме», а оперируете только академичискими знаниями.
В английской литературе по отношению к скриптам связывающим библиотеки чаще употребляется понятие «glue», то есть «клей», что точнее выражает смысл идеи нежели «обвязка» с моей точки зрения. Я как программист далёкий от альпинизма, сначала долго не понимал, что значит это слово.
Скрипт, он же сценарий — ВСТРАИМАЕВАЯ пользователем в приложение программа, служащая для расширения возможностей приложения путем выполнения прикладных операций этого приложения.
любой shell — командная оболочка, shell-скрипты расширяют ее функциональность, используя команды оболочки.
Word — прикладное приложение, программы на VBA расширяют его функциональность, используя его API.
AutoCAD — прикладное приложение, AutoLISP — скрипты.
Произвольная игрушка со скриптовым движком — приложение, логика в ней на Lua или Питоне — скрипты.
При этом отдельное приложение на Питоне — это именно приложение на Питоне, а не скрипты.
При это сложность алгоритмов, интерпретируемость/компилируемость никакого значения не имеют.
Статья — имхо, бред.
любой shell — командная оболочка, shell-скрипты расширяют ее функциональность, используя команды оболочки.
Word — прикладное приложение, программы на VBA расширяют его функциональность, используя его API.
AutoCAD — прикладное приложение, AutoLISP — скрипты.
Произвольная игрушка со скриптовым движком — приложение, логика в ней на Lua или Питоне — скрипты.
При этом отдельное приложение на Питоне — это именно приложение на Питоне, а не скрипты.
При это сложность алгоритмов, интерпретируемость/компилируемость никакого значения не имеют.
Статья — имхо, бред.
Коментаторы отжигают. вместо того что-бы обсуждать дальше тему в разрезе — «пример задач и утилит работника такой-то сферы применяемых в повседневной работе» мелочно и по школьному троллят.
Sign up to leave a comment.
Теория правильных скриптов