Я много работаю с текстом во всех его проявлениях. По своему опыту могу сказать следующее. Какой бы бред вам не пришел в голову Vim это уже умеет.
PS: ввязываться в спор emacs vs vim категорически отказываюсь. Единственное, что наверняка можно сказать про emasc это то, что это отличная операционная система. Жаль только в нем нет нормального текстового редактора ;)
Я пробовал проходить онлайн курсы на разных ресурсах. Лекции- жуть. Если бы не знал о чем говорят, то вряд-ли бы понял. Да и качество материала всегда оставляла желать лучшего. Ну и слушать как льют воду по 20-30 минут- особенно напрягает. Сдача заданий — отдельная тема. Ты их туда запихиваешь, а система глючит что подорванная. В обсуждении — сплошные жалобы на глюки. Ты пишешь письмо в суппорт и прилагаешь логи (и хорошо если они есть). Отвечают, что все хорошо и просят перезалить задание. Пробуешь. И то же самое. А потом другие глюки.И все это с паузой по нескольку дней. И все это на фоне того, что задания сформулированы как зря. И судя по вашему описанию — именно это все вас и ждет.
Как по мне проще на сайте IBM почитать очень сжатый материал по Python (2-3 дня с головой хватит), а потом взять книги по интересующему направлению и читать уже их. Ну или Лутца изучить для полного понимания.
Особенно меня умиляют фразы типа «научим пользоваться git». Что там учиться? 10 минут на сайте гита — и вы уже умеете почти все. А с учетом того, что нормальные IDE сами знают что с ним делать, то для начала достаточно будет основные определения прочитать.
В общем я не очень высокого мнения о подобных курсах. А ведь когда-то надеялся на чудо.
1. 10 устройств. З раза пересчитывал. В каждом углу по железке. 3 стационарных, ультрабук ну и все остальное.
2. Самосборный бесшумный сервер на Atome J1900 и телевизор.
3. Я инженер-связист. У меня на работе все параллельно-перпендикулярно и дома так-же. В стены вмурованы сотни метров кабеля. В комнатах розетки, в кроссовом шкафу- сами понимаете что ;)
4.100 Мbit/s
5. В эфире- адский ад. Кабель. Wi-Fi только мобильные устройства.
6. От провайдера приходит Ethernet, который включен в Wi-Fi роутер, от него в гигабитный свич, а оттуда по комнатам. Провайдер всем раздает белый IP. Настроек минимум. Иногда приходит желание пошаманить с сетью, но когда это делаешь на работе, то как-то дома уже не хочется. Жена у меня в сетях то же отлично разбирается, но говорит, что дома она блондинка и ее все устраивает.
7.Обычно один. Если вдруг он лежит подключаюсь к телефону. Автоматики никакой потому как провайдер лежит крайне редко.
8.Обновленный софт и по возможности отключено все, чем не пользуются. Резервное копирование на постоянной основе.
9.Все замуровано и сходится в кросс. Можно считать, что это профессиональная деформация. Все сделал во время последнего ремонта.
10. Не думаю, что вообще наберется много людей, которые будут делать так-же капитально как я. Лучше ли это? Для меня- да. Для других- это другим лучше знать ;)
Я первый раз о таком слышу. А хозяйка сама «понять» не могла из своих доходов? Я даже не представляю что должна давать работа в такой фирме что бы там вообще работать. С таким-то отношением.
Почему плохо? Часто это нормально. Все что нужно работает. Тем более, что упор делается на прикладной софт, а не на систему. А обновление может запросто все сломать. А это риски. А еще за уровень софта часто нужно заплатить. И заплатить немало.
Откуда они там оказались? Когда вы покупаете сервер для контроля всей сети это не железо с Linux на борту в стандартной комплектации. Это решение. Вам продают настроенную систему с целой кучей софта, который помогает вам делать все-все-все. К этому прилагается документация и поддержка на определенное время на определенных условиях. Т.е. вы звоните или пишите и вам в сжатые сроки предоставляют решения ваших проблем. И если в документации написано, что вот так вы можете использовать рекомендуемый нами Python, но так не работает, то поставщик обязан это все исправить. И не всегда это ему обходится бесплатно. Поэтому поверьте. Указанная версия стоит со всем библиотеками.
В скобках написано «из вашей статьи» и дальше вы говорите «у себя в статье». Это не моя статья. Я никак не связан ни с автором, ни с этой статьей. А вот ситуация, когда сервер стоит под семью замками и пользоваться предустановленным — самый здравый вариант мне очень хорошо знаком.
Возможно вас ввело в заблуждение название «сервер». Правильнее было бы его называть Operation Support System (OSS). Это комплекс, который используется для работы с сетью и представляет готовую систему для обслуживающего персонала. Т.е. он уже выполняет целый ряд стандартных функций таких как отслеживание аварий, статистика, билинг, конфигурирование, обновление программного обеспечения и многое-многое другое.
В смысле частные случаи? Это самый обычный случай в связи. Я не знаю о каких сетях говорите вы, а я говорю о сетях национального масштаба с тысячами роутеров. Я даже не могу себе представить идиотов, которые бы взялись это обслуживать вручную. И даже не смотря на то, что это стоит безумных денег это все покупается. Просто потому, что по-другому не получится. И еще раз повторяю. На OSS есть все, о чем заявили.
Я в самом начале написал, что можно писать на чем угодно. И готов это повторить. Вопрос не в языке. Вопрос в поддержке. Когда вы пишете на рекомендуемом языке вы используете библиотеку, которую вам предоставил производитель и работу которой он гарантирует. Вы не городите велосипеды. Вы говорите connect и библиотека сама продирается через уровни security и сама запихивает ваши команды на нужный узел или узлы. И если мы говорим о ssh, то вопросов почти нет. Во всяком случае они все решаемые. А если протокол закрыт? Допустим вы таки смогли разобраться. Но что-то пошло не так. И вы обращаетесь за консультацией к поставщику. А он мало того, что обиделся, что вы его протокол ковыряли (и еще хорошо, что санкций не последовало), так еще и очень вежливо говорит, что не собирается разбираться почему в вашем велосипедике когда вы крутите педали он мало того, что едет назад, так еще и поворачивает. И это будет очень здорово, что именно этим все закончится.
Сейчас многие производители рекомендуют Python. А с учетом того, что все сейчас ломанулись в облака, то без OpenStack точно не обойдется. А значит Python еще сильнее укрепит свои позиции как в сетях, так и в связи в целом.
Подождите. Давайте смотреть. У вас есть огромная сеть. Есть сервер, с которой эта сеть управляется. На сервере, зачастую, стоит древняя версия например Linux. Python с библиотеками уже стоят. Потому, что это предлагает поставщик. Этот сервер стоит во внутренней сети и закрыт со всех сторон фаерволами. Выхода в интернет у этого сервера, понятное дело, нет. Что бы поставить PHP вы не ставите его сами. Вы идете в службу безопасности просите, что бы вам разрешили подключить сервер с интернету для обновления и затягивания нужных пакетов. Они смотрят на вас как на двинутого и говорят нет. Точнее они говорят «Ты что вообще дебил?!!!». А вы сами расшифровываете. Потом вы решаете идти другим путем. Вы обращаетесь к поставщику. А он в свою очередь говорит, что если он поставит вам PHP, то это будет стоить столько-то денег и вообще еще нужно вот такие фичи купить. Иначе они ни за что не отвечают. А если вы что-то поставите сами и это выяснится при аудите, то сервер за все вот эти кучи денег будет снят с супорта. И даже если вам подтвердят возможность установки самостоятельно вам придется все делать руками. Это вам не aptitude install и сиди жди. Это все качать руками, приносить не место, разворачивать. А потом вот этого не хватает, а это нужно другой версии, а это слишком новое, а это… И на сервере заменять библиотеки нельзя. Может сломаться основная часть. А вам она ведь то же нужна.
Я был в такой ситуации. Поверьте. Выучить Python- плевое дело.
Вы не найдете никаких особых отличий и в других языках. Как я уже и писал можно автоматизировать на любом из них. Даже на самых экзотических. Как-то мне попалась статья, где автоматизация делалась на Haskell.
Но дело не в самих языках. Дело в производителях. Они ведь не только говорят, что используйте Python потому, что нам так нравится. Когда у вас сеть из сотен, а то и тысяч устройств вы покупаете OSS сервер (как бы он не назывался в каждом конкретном случае), который уже обладает целым рядом инструментов, но если вам нужно что-то сделать дополнительно, то у вас есть выбор написать все нужные велосипеды, а потом то, что вам нужно на любом нравящемся языке, а можно воспользоваться уже готовыми библиотеками, которые помогают вам получать данные о сети и всех устройствах, ходить на них и там получать нужные параметры, работать с данными на самом сервере. Ведь обработку статистики или обработку аварий никто не отменял. Кроме скриптом в у вас еще куча другой работы. На велосипеды просто не остается времени. Поэтому да, Python, зачастую, хороший выбор уже просто потому, что его уже выбрали.
Может быть это несколько обидно, что обошли вниманием по всей видимости любимый вами PHP, но тут только два пути. Или обижаться или выучить Python. Лично я предпочитаю второй путь. Поэтому я писал на многих языках. В том числе и на всякой экзотике, которую предлагают производители. Они могут быть кривыми и неудобными, но они позволяют быстро сделать то, что мне нужно. И это в них главное.
Написать можно, но результат не всегда вам будет нравится. Нет, работать все будет. Тут вопросов нет. Но чистый Python очень медленный. Скажем в 1000 раз медленнее, чем С++ или Java. И это не всегда подходит.
Если нет возможности поставить другой софт, то почему все будет хорошо с Python? Он, конечно, малюсенький по современным меркам, но ни как не меньше 20МB. Да и с библиотеками можно попасть в неприятную ситуацию. Особенно если это какая-то специализированная система со старым Linux. Я как-то имел удовольствие с таким повозится. Было не очень.
Я то же писал, что бы везде работал. Но язык был один. Так, по-моему удобнее.
Писать можно на чем угодно. И если вы уже знаете PHP, то почему-бы и нет? Но большинство производителей оборудования предлагают именно Python. И это о чем-то да и говорит.
Регулярки- великолепный инструмент. Сложный? Все зависит от того, на сколько сложные выражения вы используете. Можно ведь и попроще писать, а можно и посложнее, а можно и так, что у большинства людей мозг взорвется. Но каждый может их использовать на своем уровне и от этого хуже они не будут. Но при этом могут сэкономить кучу времени.
Не все поставщики позволяют фильтровать вывод. А те, что позволяют, не всегда дают достаточно свободы. Если у вас на работе приняты внутренние стандарты на все, то вы может и будете знать как будут выглядеть нужные вам поля. А если нет? Скажем вам нужно угадать как будет называться конфиг если вы знаете только то, что он может заканчиваться на cfg, cf или conf. А у особых раздолбаев и вообще быть без расширения. И тогда вам остается или все проверять руками или таки научится пользоваться Re.
PS: Если регулярки действительно очень тяжело идут, то можно использовать специальные программы, которые почти все сделают за вас. Вам останется только вставить готовую строку в ваш скрипт. На память помню только RegexBuddy, но для понимания о чем я говорю думаю хватит.
Если вы что-то автоматизировали и это отработало только один раз- это нормально и в этом нет ничего плохого. Но один раз получается очень не часто. Если мы говорим про большую сеть, то ее обслуживает и большое количество людей. И такие сети могут покрывать огромные расстояния. Вы можете даже никогда не увидеть людей, с которыми сотрудничаете годами. Представьте себе вышел из строя роутер за сотни километров от вас. Его заменил кто-то на месте и допустил ошибку при конфигурировании. И совсем не обязательно это вылезет сразу. И тут скриптик понадобится еще раз. И было бы хорошо иметь данные для сравнения и разницу получать на почту. В общем нет предела совершенству.
К тому-же если скрипт написан, то его содержание всегда можно изменить на нужное. Остальные части уже готовы. И скрипт уже будет запущен еще раз, а потом и еще раз ;)
Это запросто может быть. Например по корпоративной политике на рабочих машинах стоит Windows, а сервера, с которыми вы работаете на Windows и на Linux. Причем сервера вполне могут выполнять одни и те-же функции. И было бы хорошо, что бы скрипт работал и там и там. У меня на работе именно такой случай.
Про Win10 говорить рано. Еще только для тех, кто решился быть подопытной мышью. Да и не будем забывать, что полно оборудования где WinNT живее всех живых и Win2k3 цветет и пахнет.
На железках такого плана места действительно кот наплакал. Но там, зачастую, и скрипт не запустишь. Просто нет возможности. Но удаленно команды давать можно. Так что поставить Python нужно только в одном месте. Но я, если честно, совсем не жалуюсь. Если железка 1-2-10 вполне возможно туда что-то внедрить. Хотя то же сомнительно. А если их несколько тысяч? Лично я за то, что бы удаленно команды давать ;)
Признаюсь честно. Меня то же долго отпугивали эти пробелы. А потом мне понадобился Python и я решил, что нужно взять себя в руки. И случилось странное. Меня это абсолютно никак не напрягло. А с учетом того, что отслеживать ничего самому не нужно, все это отлично делается тем-же PyCharm, так вообще все пошло как по маслу.
Вас же в C-подобный языках фигурные скобки не смущают? И выравнивания вы все-равно делаете. И, я так подозреваю, делаете это зачастую средствами IDE. С пробелами все точно так-же.
Еще ведь и от задачи зависит. Скажем на сервере крутится вычислительное ядро, которое реализует сверх сложную с алгоритмической точки зрения задачу. И запросто может так сложиться, что добавление любого количества серверов не даст результата.
Так основная цель как раз в том, что бы уменьшить информационный поток. Или вы считаете, что лучше получать цепочки из 20 писем по каждому вопросу? Даже если хронологически они идут по порядку, то это все прочитать непросто. Ведь в середине обсуждения все еще решение не выработано, но вы все-равно вынуждены это читать что бы не потерять мысль. И этого всего много. А представьте, что обсуждение разветвляется, а потом собирается причудливым образом.
Чем больше организация, тем более важны правила. Если вы работаете в группе из 5 человек, то правила важны условно. Скажем так на уровне вежливости. В конце-концов всегда можно повернуться и спросить у человека за соседним столом что он хотел.
А теперь представьте себе, что ваша работа завязана на 50 человек. Или скажем 100-200. Все они распределены по большой территории и ваши задачи входят в конфликт с задачами других. Отслеживать ситуацию в ручном режиме уже не хватит сил ни у кого. Поэтому большая часть ложиться на всевозможные системы управления, которые в том числе берут на себя информирование, согласование и различные отчеты. Если не придерживаться правил, то все рухнет в считанные дни просто погрязнув в информационном потоке.
В такой ситуации абсолютно все заинтересованы в том, что бы сдерживать хаос. И что бы развить дополнительный интерес вводятся корпоративные стандарты, где это все описывается. Безусловно можно грести против течения и платить за это отсутствием премий и повышений, увольнением, перевариванием ненависти коллег, но зачем? Ведь можно просто найти работу в компании поменьше, где эти правила нужны условно.
Отличная статья. Просто великолепная. Только есть одна подстава подстав. Пока компания маленькая без этого всего можно с легкостью обойтись, а когда розраслась — поздняк метаться. Люди привыкли работать по-старому и их уже не переломить. Я работаю в компании с количеством сотрудников сильно больше тысячи. Когда наши менеджеры поняли, что с хаосом в переписке нужно что-то делать даже такая вещь как подпись в каждом письме кто, должность, телефон, почта потребовали титанических усилий. Вообще тема почты для меня больная. Я получаю 300-400 писем в день. Большая часть из них — автоматически формируемые рассылки и их можно отфильтровать, но от этого не всегда легче.
Что бы я добавил к правилам. В каждом письме должна быть тема. Письма без тема должны быть самым безжалостным образом уничтожены. Почтовиком. За темы «ни о чем» нужно жечь каленым железом. «Важное письмо» или «к исполнению» это не тема. Так же я бы категорически запрещал пересылать письма без внесения пояснения. Приведу пример. Приходит письмо на начальника департамента по некоторому поводу. Скажем предоставить данные о сотрудниках в форме Х. Начальник департамента рассылает всем начальникам отделов в разных частях страны просто формадом. Он в свою очередь рассылает дальше по цепочки. В результате каждый сотрудник получает письмо с кучей форвардов. Мало того, что на каждом этапе конкретный человек вчитывается во всю цепочку, так на конечном этапе письмо приходит к конкретным людям и у них встает логичный вопрос: «И что с этим теперь делать? Это должен сделать я? По подразделению или для себя? Или только для тех, кто сидит со мной в одной комнате? Или может быть это для информации?...». И пошли письма в обратном направлении. И, как часто бывает, многие даже не стали толком разбираться, а просто послали «письмо счастья» дальше. В результате они опять читают всю переписку, у них то же возникают вопросы и они задают их тому, от кого письмо пришло. Хотя если бы изначально в письме была строка типа «Выделить одного человека на отдел для агрегации данных», а дальше рассылки по отделу содержали «выслать данные Иванову». Всего этого можно было-бы избежать. И это случай, когда нужно сделать конкретные действия. А ведь бывают письма с куда более завуалированным смыслом. И все, что нужно сделать это вставить FYI что бы избежать хаоса.
PS: ввязываться в спор emacs vs vim категорически отказываюсь. Единственное, что наверняка можно сказать про emasc это то, что это отличная операционная система. Жаль только в нем нет нормального текстового редактора ;)
Как по мне проще на сайте IBM почитать очень сжатый материал по Python (2-3 дня с головой хватит), а потом взять книги по интересующему направлению и читать уже их. Ну или Лутца изучить для полного понимания.
Особенно меня умиляют фразы типа «научим пользоваться git». Что там учиться? 10 минут на сайте гита — и вы уже умеете почти все. А с учетом того, что нормальные IDE сами знают что с ним делать, то для начала достаточно будет основные определения прочитать.
В общем я не очень высокого мнения о подобных курсах. А ведь когда-то надеялся на чудо.
2. Самосборный бесшумный сервер на Atome J1900 и телевизор.
3. Я инженер-связист. У меня на работе все параллельно-перпендикулярно и дома так-же. В стены вмурованы сотни метров кабеля. В комнатах розетки, в кроссовом шкафу- сами понимаете что ;)
4.100 Мbit/s
5. В эфире- адский ад. Кабель. Wi-Fi только мобильные устройства.
6. От провайдера приходит Ethernet, который включен в Wi-Fi роутер, от него в гигабитный свич, а оттуда по комнатам. Провайдер всем раздает белый IP. Настроек минимум. Иногда приходит желание пошаманить с сетью, но когда это делаешь на работе, то как-то дома уже не хочется. Жена у меня в сетях то же отлично разбирается, но говорит, что дома она блондинка и ее все устраивает.
7.Обычно один. Если вдруг он лежит подключаюсь к телефону. Автоматики никакой потому как провайдер лежит крайне редко.
8.Обновленный софт и по возможности отключено все, чем не пользуются. Резервное копирование на постоянной основе.
9.Все замуровано и сходится в кросс. Можно считать, что это профессиональная деформация. Все сделал во время последнего ремонта.
10. Не думаю, что вообще наберется много людей, которые будут делать так-же капитально как я. Лучше ли это? Для меня- да. Для других- это другим лучше знать ;)
Откуда они там оказались? Когда вы покупаете сервер для контроля всей сети это не железо с Linux на борту в стандартной комплектации. Это решение. Вам продают настроенную систему с целой кучей софта, который помогает вам делать все-все-все. К этому прилагается документация и поддержка на определенное время на определенных условиях. Т.е. вы звоните или пишите и вам в сжатые сроки предоставляют решения ваших проблем. И если в документации написано, что вот так вы можете использовать рекомендуемый нами Python, но так не работает, то поставщик обязан это все исправить. И не всегда это ему обходится бесплатно. Поэтому поверьте. Указанная версия стоит со всем библиотеками.
В скобках написано «из вашей статьи» и дальше вы говорите «у себя в статье». Это не моя статья. Я никак не связан ни с автором, ни с этой статьей. А вот ситуация, когда сервер стоит под семью замками и пользоваться предустановленным — самый здравый вариант мне очень хорошо знаком.
Возможно вас ввело в заблуждение название «сервер». Правильнее было бы его называть Operation Support System (OSS). Это комплекс, который используется для работы с сетью и представляет готовую систему для обслуживающего персонала. Т.е. он уже выполняет целый ряд стандартных функций таких как отслеживание аварий, статистика, билинг, конфигурирование, обновление программного обеспечения и многое-многое другое.
В смысле частные случаи? Это самый обычный случай в связи. Я не знаю о каких сетях говорите вы, а я говорю о сетях национального масштаба с тысячами роутеров. Я даже не могу себе представить идиотов, которые бы взялись это обслуживать вручную. И даже не смотря на то, что это стоит безумных денег это все покупается. Просто потому, что по-другому не получится. И еще раз повторяю. На OSS есть все, о чем заявили.
Я в самом начале написал, что можно писать на чем угодно. И готов это повторить. Вопрос не в языке. Вопрос в поддержке. Когда вы пишете на рекомендуемом языке вы используете библиотеку, которую вам предоставил производитель и работу которой он гарантирует. Вы не городите велосипеды. Вы говорите connect и библиотека сама продирается через уровни security и сама запихивает ваши команды на нужный узел или узлы. И если мы говорим о ssh, то вопросов почти нет. Во всяком случае они все решаемые. А если протокол закрыт? Допустим вы таки смогли разобраться. Но что-то пошло не так. И вы обращаетесь за консультацией к поставщику. А он мало того, что обиделся, что вы его протокол ковыряли (и еще хорошо, что санкций не последовало), так еще и очень вежливо говорит, что не собирается разбираться почему в вашем велосипедике когда вы крутите педали он мало того, что едет назад, так еще и поворачивает. И это будет очень здорово, что именно этим все закончится.
Сейчас многие производители рекомендуют Python. А с учетом того, что все сейчас ломанулись в облака, то без OpenStack точно не обойдется. А значит Python еще сильнее укрепит свои позиции как в сетях, так и в связи в целом.
Я был в такой ситуации. Поверьте. Выучить Python- плевое дело.
Но дело не в самих языках. Дело в производителях. Они ведь не только говорят, что используйте Python потому, что нам так нравится. Когда у вас сеть из сотен, а то и тысяч устройств вы покупаете OSS сервер (как бы он не назывался в каждом конкретном случае), который уже обладает целым рядом инструментов, но если вам нужно что-то сделать дополнительно, то у вас есть выбор написать все нужные велосипеды, а потом то, что вам нужно на любом нравящемся языке, а можно воспользоваться уже готовыми библиотеками, которые помогают вам получать данные о сети и всех устройствах, ходить на них и там получать нужные параметры, работать с данными на самом сервере. Ведь обработку статистики или обработку аварий никто не отменял. Кроме скриптом в у вас еще куча другой работы. На велосипеды просто не остается времени. Поэтому да, Python, зачастую, хороший выбор уже просто потому, что его уже выбрали.
Может быть это несколько обидно, что обошли вниманием по всей видимости любимый вами PHP, но тут только два пути. Или обижаться или выучить Python. Лично я предпочитаю второй путь. Поэтому я писал на многих языках. В том числе и на всякой экзотике, которую предлагают производители. Они могут быть кривыми и неудобными, но они позволяют быстро сделать то, что мне нужно. И это в них главное.
Если нет возможности поставить другой софт, то почему все будет хорошо с Python? Он, конечно, малюсенький по современным меркам, но ни как не меньше 20МB. Да и с библиотеками можно попасть в неприятную ситуацию. Особенно если это какая-то специализированная система со старым Linux. Я как-то имел удовольствие с таким повозится. Было не очень.
Я то же писал, что бы везде работал. Но язык был один. Так, по-моему удобнее.
Не все поставщики позволяют фильтровать вывод. А те, что позволяют, не всегда дают достаточно свободы. Если у вас на работе приняты внутренние стандарты на все, то вы может и будете знать как будут выглядеть нужные вам поля. А если нет? Скажем вам нужно угадать как будет называться конфиг если вы знаете только то, что он может заканчиваться на cfg, cf или conf. А у особых раздолбаев и вообще быть без расширения. И тогда вам остается или все проверять руками или таки научится пользоваться Re.
PS: Если регулярки действительно очень тяжело идут, то можно использовать специальные программы, которые почти все сделают за вас. Вам останется только вставить готовую строку в ваш скрипт. На память помню только RegexBuddy, но для понимания о чем я говорю думаю хватит.
К тому-же если скрипт написан, то его содержание всегда можно изменить на нужное. Остальные части уже готовы. И скрипт уже будет запущен еще раз, а потом и еще раз ;)
Про Win10 говорить рано. Еще только для тех, кто решился быть подопытной мышью. Да и не будем забывать, что полно оборудования где WinNT живее всех живых и Win2k3 цветет и пахнет.
На железках такого плана места действительно кот наплакал. Но там, зачастую, и скрипт не запустишь. Просто нет возможности. Но удаленно команды давать можно. Так что поставить Python нужно только в одном месте. Но я, если честно, совсем не жалуюсь. Если железка 1-2-10 вполне возможно туда что-то внедрить. Хотя то же сомнительно. А если их несколько тысяч? Лично я за то, что бы удаленно команды давать ;)
Вас же в C-подобный языках фигурные скобки не смущают? И выравнивания вы все-равно делаете. И, я так подозреваю, делаете это зачастую средствами IDE. С пробелами все точно так-же.
1. Все должно быть зафиксировано.
2. Не плодить информационный мусор.
Вы считаете это сложным?
PS: Если да, то я не вижу смысла продолжать.
А теперь представьте себе, что ваша работа завязана на 50 человек. Или скажем 100-200. Все они распределены по большой территории и ваши задачи входят в конфликт с задачами других. Отслеживать ситуацию в ручном режиме уже не хватит сил ни у кого. Поэтому большая часть ложиться на всевозможные системы управления, которые в том числе берут на себя информирование, согласование и различные отчеты. Если не придерживаться правил, то все рухнет в считанные дни просто погрязнув в информационном потоке.
В такой ситуации абсолютно все заинтересованы в том, что бы сдерживать хаос. И что бы развить дополнительный интерес вводятся корпоративные стандарты, где это все описывается. Безусловно можно грести против течения и платить за это отсутствием премий и повышений, увольнением, перевариванием ненависти коллег, но зачем? Ведь можно просто найти работу в компании поменьше, где эти правила нужны условно.
Что бы я добавил к правилам. В каждом письме должна быть тема. Письма без тема должны быть самым безжалостным образом уничтожены. Почтовиком. За темы «ни о чем» нужно жечь каленым железом. «Важное письмо» или «к исполнению» это не тема. Так же я бы категорически запрещал пересылать письма без внесения пояснения. Приведу пример. Приходит письмо на начальника департамента по некоторому поводу. Скажем предоставить данные о сотрудниках в форме Х. Начальник департамента рассылает всем начальникам отделов в разных частях страны просто формадом. Он в свою очередь рассылает дальше по цепочки. В результате каждый сотрудник получает письмо с кучей форвардов. Мало того, что на каждом этапе конкретный человек вчитывается во всю цепочку, так на конечном этапе письмо приходит к конкретным людям и у них встает логичный вопрос: «И что с этим теперь делать? Это должен сделать я? По подразделению или для себя? Или только для тех, кто сидит со мной в одной комнате? Или может быть это для информации?...». И пошли письма в обратном направлении. И, как часто бывает, многие даже не стали толком разбираться, а просто послали «письмо счастья» дальше. В результате они опять читают всю переписку, у них то же возникают вопросы и они задают их тому, от кого письмо пришло. Хотя если бы изначально в письме была строка типа «Выделить одного человека на отдел для агрегации данных», а дальше рассылки по отделу содержали «выслать данные Иванову». Всего этого можно было-бы избежать. И это случай, когда нужно сделать конкретные действия. А ведь бывают письма с куда более завуалированным смыслом. И все, что нужно сделать это вставить FYI что бы избежать хаоса.