Комментарии 21
Ради интереса, могу высказать свою точку зрения, хотя следовать ей не обязательно.
Мое мнение, фундаментальные науки, вроде математики, надо учить в ВУЗах, у классных преподавателей, которых будешь вспоминать годами. А науки «второго уровня», вроде иностранных языков, программирования и т.п., надо учить самостоятельно, за исключением разве что спецконтор, где требования могут быть на порядок выше.
Исходить нужно из класса решаемых задач. Когда учащийся плохо себе представляет, зачем ему нужен очередной «язык» (иностранный или программирования), но есть желание потратить на это время на каких-нибудь курсах, особенно, за счет фирмы, то «почему бы и да», пусть учится, само по себе, в этом ничего плохого нет.
Однако, активно мыслящие специалисты, предпочитают учить себя сами. Возьмем тот же Питон. Главный вопрос – это основное предназначение данного языка. Кто-то считает его универсальным языком программирования, я же полагаю, что это язык для обработки и подготовки данных. Здесь ему равных нет. Естественно, применять его можно и за этими пределами, для построения GUI и даже игр. Но, как по мне, есть более удобные средства для этого.
Например, с помощью Питона (и FFmpeg) можно создавать обучающие видео, по тому же иностранному языку (примеры на my.mail.ru/mail/emmerald/video/_myvideo ), а если написать на С++ обучающую программу, то и данные для нее (см. scholium.webservis.ru ).
Непосредственно курсов программирования, обучающих этому не найти, но сам язык достаточно прост, чтобы выучить его самостоятельно и затем решить поставленную перед собой задачу. Понятно, что другим это не надо, поэтому соответствующих курсов организовывать не нужно, достаточно написать пару статей на данную тему.
А по обучению иностранном языкам, очень удобно использовать идею: «запоминание руками + интерактивный звук», как по, мне это очень практичная идея. Работаешь на уровне отдельной фразы, набираешь ее руками, прослушиваешь сколько угодно раз и проговариваешь ее вслед, чтобы, в конечном счете, посмотреть и понять всё видео с двуязычными субтитрами, а затем и оригинальный ролик. Вот как раз для подготовки подобных данных Питон – незаменимая вещь.
Спасибо за развернутый комментарий. Да, мы с помощью курса пытались решить именно наши задачи. Как получилось — лучше расскажут сами участники обучения (а также те, с кем они вместе работают).
По поводу деления наук на «первый и второй уровни» — спорное утверждение. Хорошая вузовская программа предусматривает теорию (лекции, семинары) и практику (лабы, курсовые). Алгоритмы, дискретная математика, теория формальных языков, реляционная алгебра — это теория. А написание кода на конкретном языке — это, конечно же, практика.
В наших условиях мы, конечно же, можем дать в основном практику. Теорию — только «по верхам», в расчете, что кто-то заинтересуется и пойдет читать книжки.
Хорошо, конечно, но почему это на хабре, а не в вашей местной этушке?
Ради списка из трёх книг/курсов и одной ссылки на checkio?
В нашей местной... в чём, простите? Расшифруйте, пожалуйста :)
Внутреннем "хабре" для сотрудников, если вкратце -)
Статья — попытка начать дискуссию на тему «почему инженер/админ/связист боится/не хочет написать нужный ему по работе кусок кода» и как ему можно помочь (захотеть). Вернее, вынести наши внутренние обсуждения на эти темы на более широкую аудиторию. Готовы об этом поговорить?
Потому что инженера/админа/связиста заставляют "написать" на строго определённом ЯП, принятом в компании, соблюдая code-style (обычно - достаточно сложный), принятый в компании, используя либы, написанные в компании взамен общедоступных, а на баше/powershell и в ансибл писать запретили ? -)
Ну точно не про нашу компанию, и не про наше подразделение. У нас скорее другая проблема — когда молодой и очень старательный инженер в текстовом редакторе перепиливает 100500 правил ACL из формата, условно, cisco, в формат, условно, iptables, и пользуется максимум поиском/заменой. Хотя никто не запрещает ни bash, ни awk, ни регулярные выражения, ни perl, ни python.
Хорошо вам -)
Только курсы-то у вас всё равно по python.
А лично моя практика показывает, что решая ops-задачи на python, тратишь 10% времени на логику приложения/скрипта, а остальные 90% - на, собственно, сам python (приведение типов данных к одному, try/except и вот это вот всё).
Это, конечно, не отменяет того, что некоторые (подчёркиваю - некоторые) задачи нужно сразу автоматизировать на python и не тратить время на троллейбус из буханки (например, вебморда и обработка данных от пользователей - шеллы сразу идут лесом), но вот пихать его везде подряд (а уж тем более - начинать с него обучение как первому языку для опса) - весьма затейливая идея, которая быстро вызывает отвращение к любым ЯП. Особенно если использовать python вместо awk-а.
Давайте воспользуемся принципом «критикуешь — предлагай». К питону как к первому языку у меня тоже масса вопросов, но на чём ещё учить?
В вузах сейчас учат в основном сразу на несуществующем языке «С/С++» (ибо «индустрия требует»), и ребята приходят к нам уже с психотравмой и стойким отвращением к написанию кода.
Идти по пути, предлагаемому Столяровым — методически правильно, но на это нужен плюс-минус год.
Какие ещё есть варианты?
Ну давайте прямо к вашим задачам.
в текстовом редакторе перепиливает 100500 правил ACL из формата
Этим стоит начать с awk, sed и так далее. А потом поучить shell - настолько, чтобы понимать, что [ - это команда, и вместо неё в if можно использовать любую другую (в том числе и сабшелл ()).
положить кучу устройств
Этим нужно показать ansible и запуск по стейджам.
При том показать не только то, что ansible умеет пакетики ставить и файлики подкладывать, но и что он, например, почти полностью может настроить zabbix (что даёт какой-никакой monitoring as a code) и настраивать микротики. А там уже постепенно переходить к jinja-шаблонам/циклам.
Ансибл вообще великолепный инструмент, который одновременно прививает мышление "everything as a code" с одной стороны, а с другой стороны не ломает паттерны мышления сходу людям, которые мыслят как классические опсы. Главное, не забыть им рассказать, почему ансибл не декларативен на самом деле в 90% случаев.
несуществующем языке «С/С++»
Этим (если они хотят продолжить!) можно и нужно показать golang. Можно, конечно, ещё rust, но где они потом работу искать будут - вопрос интересный. Можно и python, впрочем - но, опять же, если хотят.
Но безапялицонно показывать людям python как первый инструмент для автоматизации ops-работы - плохой путь. Это полноценный ЯП, который требует определённого мышления и достаточно глубоких знаний - и не все, кто пришёл в ops, хотят идти этим путём. А то потом очень смешно смотреть на sys.exec('curl', '...') в коде бывает, когда это из под палки идёт.
Лет 10 назад, впрочем, был перл - его так и не заменили, но забросили. А зря.
Про shell и ansible — всё так и есть, а дальше возникают вопросы
можно и нужно показать golang. ... безапялицонно показывать людям python как первый инструмент для автоматизации ops-работы - плохой путь. Это полноценный ЯП
golang я не знаю (видел издали, слышал хорошие отзывы, но ни строчки кода на нём не написал), впечатления от него — это хороший, полнофункциональный язык, особенно для того чтобы быстро и качественно написать backend-часть веб-приложения.
Почему вы его противопоставляете питону, называя питон «полноценным ЯП»? Чем golang менее «полноценен»?
а дальше возникают вопросы
А дальше возникать вопросов не должно, дальше - другая профессия, как её ни назови, освоить которую на "курсах" не выйдет.
Почему вы его противопоставляете питону
Я противопоставляю шелл питону, а не golang -)
Нельзя научиться нормально программировать на каких-то курсах, посвящая этому пару часов в неделю. Чтобы писать и на golang, и на python, и на любом другом полноценном ЯП - нужно знать много базовых вещей - типы данных, алгоритмы, ООП, внутренняя логика ЯП и остальное.
Можно ли это выучить за, допустим, 100 академических часов? Нет.
А дальше 2 варианта - либо человек сидит и использует только стандартные заученные конструкции в коде и не может ничего толком написать (зачем ему тогда пайтон, если конструкции в ансибле запомнить проще?), либо - сидит и страдает, пытаясь реализовать простые вещи, которые знают "настоящие" программисты, используя свой скудный набор знаний - и тратит туеву прорву времени на элементарные программы, начиная ненавидеть сам процесс всё больше и больше.
На «каких-то курсах» научиться «нормально» нельзя ничему — здесь задача осуществить bootstrap и показать направление, куда двигаться (это вообще любых курсов касается).
Верно и обратное — те сотрудники, которым можно показать направление, и они сами начинают в том направлении идти, быстрее всех прогрессируют, и очень ценятся работодателями.
А дальше 2 варианта - либо человек сидит и использует только стандартные
заученные конструкции в коде и не может ничего толком написать (зачем
ему тогда пайтон, если конструкции в ансибле запомнить проще?)
Это вообще самый сложный вопрос подготовки (и самоподготовки) любого специалиста — как сделать так, чтобы знания сложились в систему. Здесь нет однозначного ответа (за годы преподавательского опыта я его так и не нашел). Мне кажется, что нужные нейронные связи будущий специалист может сформировать только сам — пробуя, ошибаясь, размышляя, и берясь за всё более сложные задачи. Это стресс, это боль, но пойти по «простому» пути (годами использовать стандартные конструкции для решения стандартных задач) — тоже невесело, и ценность такого специалиста будет со временем падать.
Это вообще самый сложный вопрос подготовки (и самоподготовки) любого специалиста — как сделать так, чтобы знания сложились в систему
Нужно превратить этот вопрос в "как позвать на курсы тех, кому оно надо", вот и всё.
Что, конечно, противоречит общей тенденции "давайте не делать нормальные инструменты, пущай на питоне пользователи напишут", но зато очень продуктивно в перспективе в большом опс-отделе - заинтересованные люди будут писать автоматику, остальные люди будут ей пользоваться.
ценность такого специалиста будет со временем падать.
Ценность сотрудника, который несколько часов пишет 5 строк на питоне тоже не сильно растёт - он при этом дропает ту работу, которую мог хорошо и быстро сделать. Не говоря уже о том, что обязаловка с ЯП бьёт по синдрому самозванца даже тех, кто хорошо справляется с той работой, на которую его вообще-то говоря нанимали.
Нужно превратить этот вопрос в "как позвать на курсы тех, кому оно надо"
Можно поставить вопрос ещё шире — например, «как принять на работу тех, кто будет хорошо работать». Пока наша концепция (для начинающих специалистов) — чтобы был интерес к тому, чем мы занимаемся (и к ИТ в принципе). Остальному можно научить и научиться.
Так вы нанимаете на работу людей для одной работы, а потом предлагаете учить им совершенно другую работу -)
Если у вас задача сделать из своих джунов программистов, чтобы они сменили профессию и перестали заниматься опсом - это один вопрос.
Если вам нужно растить опсов, чтобы они оставались опсами - то лучше поучить их другим вещам.
Людей, которые, будучи джуном в одной профессии, смогут успешно осваивать вторую, не забив на первую - исчезающе мало
Идёт 2022 на Хабре досехпор выходят , статейки про курсы питухона. С советами и книгами которые , есть в каждой такой теме с 2019. Ну не интересно это уже.
Масло масляное xD
Любопытная дискуссия, но есть нюансы.
Автор статьи - о своем опыте обучения (неплохо бы дополнить статью сведениями - сколько каких задач и как решили выпускники курсов), его оппонент - о вопросах выбора первого языка и инструментов для ops'ов.
Стоит задаться вопросом, насколько посетители курсов являются ops'ами. Джет - системный интегратор. Там работают, например, проектировщики. Им как раз нужно обрабатывать входные данные для проекта (например, выводы команд с разных устройств).
А для этой задачи, все-таки python как-то подходит:
...это язык для обработки и подготовки данных.
Как это могут применять инженеры, настраивающие оборудование - материал уже был на хабре (кстати, автор той статьи - выпускник курсов).
За эксплуатацию не скажу. А они как раз ближе к понятию "настоящего ops'а". Для настройки сетевого железа ansible действительно может быть средством первого выбора. Особенно в совокупности с механизмами bootstrap/ztp. Все таки netmiko/paramiko и аналогичные библиотеки требуют обертки в коде, конструкция может быть громоздкой, что, судя по всему, имел ввиду оппонент. Пока все предусмотришь - умаешься.
Не планирую спорить, просто поделюсь причинами, почему лично я использую python для задач анализа информации с сетевого оборудования (как правило, это конфигурации и выводы диагностических команд):
это работает. За вечер-другой пачка файлов с листингами конфигов и диагностики превращаются в юзабельные таблички. Руками перебирать по 150-200 конфигов - вообще не вариант.
готовые библиотеки (пример - TextFSM), шаблоны, документация для них;
документация, книги, описание библиотек;
бесплатное IDE с отладчиком (PyCharm);
больше как-то особо и нечего применять. Я не программист, просто сочувствующий. Знал бы исходно perl или shell (то и другое вызывает некоторую негативную реакцию на уровне подсознания) - может на них бы и писал.
PS: С автором статьи знаком, на курсы не ходил.
В любом случае, это деньги. Сэкономленные или вырученные. А потом уже вот это вот всё.
Что не так с курсами по программированию, и зачем мы запустили еще один по Python