От подписчиков: У меня тоже 5 копеек к вопросу https://t.iss.one/it_human/463. На курсах тестировщиков был блок по Git. Помню, чуть не плакала, когда домашние задания делала часами (тупила, что гуманитарий и 36 лет 😬). А сейчас Гит люблю нежно и трепетно 😍 Почти как Ваш канал 😇 А вообще, задавать вопросы и искать ответы (даже при выполнении ДЗ) - это суперполезный в дальнейшем навык 💪

#вашивопросы

Меняю профессию, изучаю JavaScript, React, Redux

Такой вопрос: бывает, что некоторые самоучки учат много, а потом может оказаться, что все, что они учили, - это не то для какой-то конкретной компании и вообще ещё нужно знать вагон и тележку, чтоб взяли на определённую вакансию.

Гуглю какие-то вакансии, а там в требованиях бесконечный список знаний и умений. При взятии на работу ДЖУНА предпочтение отдаётся больше софтскилам или знанию языка программирования и надстроек языка, фреймворков?

И вообще , насколько важно знать технические основы, потому что многие гуманитарии смотрят CS50 на ютубе все, достаточно ли этих технических знаний работодателям при найме ДЖУНА?

Честно говоря, я не очень верю, что самоучки могут выучить слишком много всего лишнего - потому что помимо вашей специализации (фронтэнд) есть еще базовая компьютерная грамотность. Помните, мне недавно задавали вопрос - там девушка пришла на работу со знаниями фронтэнда, и столкнулась с тем, что коллеги стали намекать, что хоть всё и ок, но всё же на их взгляд, ей не хватает базы.

Достаточно ли CS50 для того, чтобы вас взяли на работу? - Думаю, вы сами понимаете, что CS50 - это введение в информатику, там не дают специализации - тому же фронтэнду вы потом учитесь уже где-то в другом месте. Также там не дают глубокого погружения в отдельные темы, которые могут пригодиться - ну например, в сетевые протоколы, в базы данных и так далее. Поэтому если работодатель указал в вакансии «знание сетевых протоколов» - лучше, к примеру, почитать книгу, с углублением именно в эту тему, одним cs50 не обойтись.

Вы вот спрашиваете, сколько знаний нужно джуну. В этом вопросе меня немного смущает кое-что. Вот вы пришли в качестве джуна, и, допустим, вы не знаете, что такое «память компьютера» (не вымышленный пример - спрашиваю у джуна, сколько памяти использует его программа, а он отвечает «я не знаю, что такое «память»»). Так откуда же у вас возьмётся знание базы к тому времени, как вы уже станете ближе к middle-разработчику? Ведь много учиться и совмещать это с работой уже не получится, у вас будут другие задачи. В процессе работы вы скорее всего наработаете навыки в рамках своей узкой специализации - то есть JS и всё вокруг него, а вот общую грамотность так прокачать сложнее - времени не хватит. Джун в моем понимании - это человек без опыта, но со знаниями.

Что касается требований в вакансиях - там обычно перечисляют не базовые знания, о которых я говорила в предыдущих абзацах, а конкретные технологии - языки программирования, фреймворки для работы с ними, системы контроля версий и разные тулзы, которые нужны для разработки и запуска ваших программ. Если вы открываете список вакансий и видите там кучу непонятных вам слов - рекомендую почитать и поизучать, что это такое - хотя бы на уровне ликбеза.

Но слишком бояться забора из требований тоже не стоит - работодатель обычно хочет найти идеального кандидата - то есть со знанием всех технологий, которые используются в этой компании. А на практике таких кандидатов практически и нет. Поэтому если видите, что вам знакомы 70-80% технологий, которые упоминаются в вакансии - можете смело откликаться.

Что касается вопроса - что важнее для работодателей - софт-скиллы или знания и навыки (хард-скиллы) - ну вы так спрашиваете, как будто все работодатели одинаковые. Всё зависит от того, к кому вы попадёте не собеседование. Одни готовы взять новичка с недостающими знаниями - если видят в нём потенциал, и верят, что он сможет прокачаться во всём, что не знает. Другие, наоборот - будут придираться к знаниям.

С софт-скиллами вообще всё сложно - все о них говорят, но мало кто понимает, как их проверять. Я часто слышу точку зрения, что лучше человек с сильными софт-скиллами, но со средненькими знаниями - ведь знания можно прокачать, а вот софт-скиллы не так легко. Но это не значит, что вас будет собеседовать человек, который тоже исповедует такую идеологию - все люди разные, и подходы к найму у всех отличаются.

Задать вопрос автору блога можно здесь: @hum_it_bot

Good news everybody!

Мне тут написали из GeekBrains и прислали промокод со скидкой для подписчиков канала - IT_HUMAN. До конца апреля он даёт дополнительные скидки на курсы - до 50%.

Если вас интересуют другие школы программирования, я тоже могу поискать подходящие промокоды для вас - черканите в @hum_it_bot, возможно что-то найдётся и для них

Чтобы получать больше полезных материалов по ИТ и бизнесу, присоединяйтесь к сообществу @SelectelNews 🦖

#вашивопросы

Здравствуйте! DevOps это сисадмин с элементами знаний программиста, или программист, который полностью может и заменить сисадмина? Или таковыми могут называть всех, кто знает и ту, и другую работу?

Я вижу началась путаница в терминах, всё ж таки «гибрид» программиста с админом - это скорее метафора.

Давайте разберёмся, что значит DevOps. Прежде всего, это не человек и не профессия, DevOps - это процесс, либо методика разработки и поставки готовых программ пользователю. Расшифровывается это слово как Development + Operations, development - это собственно разработка программ, а operations - эксплуатация, то есть сборка, поставка в продакшен, мониторинг за работоспособностью программ.

Представим какой-нибудь продукт, например, поисковик яндекса - Dev - это разработчики, которые придумывают алгоритмы поисковика и пишут код, а Ops - это люди, которые получают от разработчиков готовый код, создают из него сборку, готовую для выкладывания в продакшен, собственно релизят новые версии (и тогда у пользователей появляется, например, новые возможности при использовании поисковика). Также эти люди следят за специальными графиками, на которых видно, насколько хорошо работает сайт, сколько там пользователей, хватает ли на всё ресурсов, есть ли какие-то проблемы. И если проблемы есть - оперативно их решают, например, откатывают код до предыдущей версии. В общем, это люди, которые отвечают за работоспособность конечного продукта.

Что же такое DevOps? Девопс - это процесс или идеология или методика, как угодно, которая подразумевает объединение функционала Dev и Ops. Либо сближение и более тесное взаимодействие этих двух областей.

В некоторых компаниях, особенно небольших, это означает, что сами разработчики не только пишут код, но и выкладывают его в продакшен, мониторят производительность и следят за работоспособностью сервисов. Таким образом ответственность не размазывается между разными отделами - отделом Dev и отделом OPs, сам написал программу - сам позаботься, чтобы она работала.

А в других компаниях появляется отдельная профессия, така как DevOps - инженер. Чаще всего это человек, отвечающий за автоматизацию процесса деплоя программ. То есть его задача - организовать такую инфраструктуру, чтобы новая версия кода автоматически отправлялась на сборку, тестирование и, скажем, по одному нажатию кнопки - обновлялась в продакшене (и так же легко откатывалась обратно в случае неполадок).

Почему DevOps - инженеров называют смесью админов и программистов? Админами потому что - это люди, которые в том числе настраивают железо, а также всю инфраструктуру для того, чтобы на них запускать программы и приложения. А почему они как бы «на полшишечки» программисты - потому что их задача в том числе - собирать, запускать, тестировать и релизить программы и следить, чтобы эти программы работали. В их обязанность не входит собственно создавать эти программы, писать код для них, но они должны понимать - что вообще такое программа, как она работает, как из нее собрать и запустить работающий проект и какие при этом могут быть узкие места. Также DevOps-у может потребоваться умение писать хотя бы небольшие скрипты для автоматизации его задач.

Поэтому отвечая на ваш вопрос - DevOps-инженер - это в первую очередь сильный администратор, с глубокими знаниями именно тех технических аспектов, которые нужны для процесса DevOps. А процесс разработки ему требуется знать хотя бы на уровне ликбеза, Senior-программистом быть не обязательно.

И как счас называют сисадминов, что за серверы отвечают? Есть же навен ещё у них свой старший? Наподобие тимлида у программистов

Админов, которые отвечают за сервера, называют администраторами серверов (неожиданно, правда?). А старших среди них называют старшими администраторами, тех, кто руководит командой - называют тимлидами, а самых старших - руководителями отделов. Есть еще технический директор, но это обычно руководитель уже над всем IT в компании, не только над админами. 🙂

Задать вопрос автору блога можно здесь: @hum_it_bot

#вашивопросы

Я изучаю Python, по видеокурс от Tceh (Может слышали про такой?) и по книжке Свейгарта "Автоматизация рутины". И чем больше я узнаю, тем больше понимаю, что ничего не понимаю и как много еще нужно выучить. И на некоторые темы приходится тратить столько времени, и концентрации что я уже начинаю подзабывать прошлые. Было ли у вас такое? И как вы с этим справлялись? Если постоянно возвращаться к старому, то прогресс в изучении минимальный. А к другим инструментам изучения у меня в данный момент нет доступа.(Работаю в море, интернета здесь хватает на телеграмм и максимум какие-то статьи найти.)

У меня из вашего вопроса создалось ощущение, что у вас есть некий перекос в сторону изучения теории.
Ну во-первых, ничего «выучивать» не нужно - теория нужна для того, чтобы достигнуть понимания общих принципов, лежащих в основе программирования, того, как всё устроено, и использовать эти знания для написания кода - они помогают выбрать лучшее решение (например, более эффективное, и не содержащее ошибок). Сама по себе зубрёжка материала без понимания где и как этот материал применять - бесполезна.

Python - это инструмент, такой же как, например, дрель. Можно бесконечно читать какие-нибудь книги о том, как правильно пользоваться дрелью, но вряд ли в этом есть толк, если очень редко её брать в руки.

Поэтому чтобы изучить Python - решайте больше практических задач. Пишите программы, придумывайте себе новые задачи и реализуйте их. Какие программы писать? Процитирую свой же старый пост:

А что именно писать? Да всё подряд. Напишите простенькую игру (поначалу можно консольные) - виселицу, крестики-нолики, морской бой, пинг-понг. Напишите небольшой сайт для себя. Напишите календарь с уведомлениями, напишите программу со списком дел. Напишите телеграм-бота, который будет вам присылать каждый день мотивирующую фразу, или курс валют, или прогноз погоды. Пишите, всё, что угодно - любую фигню, которая вам приходит в голову.

Или вот оттуда возьмите идеи для проектов.

Ваша цель - научиться решать всевозможные задачи с помощью Python, а теоретический материал нужен для того, чтобы облегчать вам эту задачу - но и не забывайте про путь проб и ошибок, он тоже чуть ли не важнейшая часть обучения.

Задать вопрос автору блога можно здесь: @hum_it_bot

#вашивопросы

Интересует такой вопрос: как пройти техническую часть собеседования, если даже на простых вопросах у меня возникает ступор? Как вообще запоминать такие огромные объемы информации, которые могут понадобиться для прохождения технической части собеседования?

Этот вопрос мне напоминает предыдущий от другого подписчика.

«Запоминать огромные объемы информации» для меня звучит как зубрежка без понимания сути. Я не сторонник «выучивания» материала - главное добиться понимания, умения рассказать своими словами, как что устроено. Когда читаете книгу или статью - старайтесь уловить суть и ответить для себя на вопрос - почему это информация важна и как её можно и нужно учитывать при написании кода (если вы программированием собираетесь заниматься).

Что касается заучивания ответов - некоторые перед тем как идти на собеседование гуглят самые распространненные вопросы, которые задают кандидатам на данную вакансию, и запоминают ответы на них. И в каких-то случаях на собеседованиях это прокатывает - не всегда интервьюер догадается, что вы этот вопрос загуглили впервые полчаса назад.

Но более опытные интервьюеры стараются копать вглубь. И услышал поверхностный ответ на вопрос, задают много уточняющих вопросов, чтобы понять, есть ли у вас реально понимание темы.

И помним, что практика всегда идёт впереди теории - важнее уметь писать код, чем отвечать на вопросы а-ля экзамен.

Задать вопрос автору блога можно здесь: @hum_it_bot

​​Вебинар «Открытое алгоритмическое собеседование»

В интернете можно найти множество статей, в которых написано, что нужно делать, чтобы успешно пройти собеседование. Но это всё теория, 12 мая мы проведём самое настоящее, непостановочное алгоритмическое собеседование: покажем, как оно проходит на практике, расскажем, почему собеседования проводятся в таком формате, на что интервьюеры обращают внимание и из чего складывается итоговое впечатление о кандидате. После собеседования мы ответим на ваши вопросы.

Проведёт собеседование Илья Акользин — автор курса «Алгоритмы для разработчиков» в Яндекс.Практикуме. Собеседоваться будет Илья Архипов — выпускник курса, разработчик DLP системы Falcongaze SecureTower.

Для кого вебинар будет полезным?
- Для тех, кто планирует когда-нибудь проходить алгоритмическое собеседование.
- Для тех, кто сам проводит собеседования.
- Для тех, кому интересно, зачем это всё нужно.

12 мая в 19:30 (Мск)

👉 Подробности и регистрация

Из ваших вопросов у меня создаётся впечатление, что многие заходят как будто не с того конца.

Многие мои подписчики, когда просят совета, рассуждают примерно так: сделать первый шаг в IT - это что-то очень серьёзное, на это нужно долго решаться, минимум полгода выбирать курсы, читать отзывы, и думать, думать, думать - готов ли ты к таким крупным переменам в своей жизни, как бросить всё и идти учиться, менять профессию. Ну и, конечно, морально готовиться отдавать 100 тысяч рублей за какие-нибудь курсы.

А, как по мне, первый шаг должен выглядеть вообще не так. Вы ещё ничего не знаете об IT, максимум то, что вам рассказали маркетологи, которые рекламируют курсы. То есть ничего. Даже если вы убеждены, что в IT - хорошо, на этом этапе ещё рано об этом судить - возможно, вам не понравится. Вы же ещё даже не попробовали, откуда вы знаете?

А чтобы понять, что это такое, и надо ли оно вам - нужно сделать первый шаг. Не ждать, не думать, не сомневаться, не взвешивать какие-то «за» и «против» и даже не читать статьи на Хабре - всё это по сути прокрастинация, и она вас никуда не сдвинет. Что же такое первый шаг? Да хоть книжку какую-нибудь купить и прочитать, и попробовать повторить примеры из неё. Интересует администрирование - почитайте про линукс, например (интересует программирование - тоже про линукс почитайте). Или курс какой-нибудь бесплатный пройдите - они есть в Интернете, если искать не только на топ-5 рекламируемых платформах.

Попробуйте, поэкспериментируйте, проработайте примеры и учебные упражнения. Если речь идёт о программировании - напишите какую-нибудь маленькую простую программу (ну, скажем, игру «виселица» или «крестики-нолики» - консольную). И вот тогда, в процессе, уже ответьте себе на вопрос - вам интересно? Хотели бы лучше в этом разбираться? Хотели бы больше времени посвящать обучению? Хотели бы в будущем устроиться на работу, где будете заниматься такой работой?

А когда люди даже близко не представляют себе, чем вообще занимаются программисты, но уже пытаются что-то «решать» - получается не всегда что-то радужное.

Регулярные выражения

Если у вас есть проблема и вы решили использовать регулярные выражения, у вас уже две проблемы. (с)

Сегодня хочу рассказать о регулярных выражениях тем, кто пока не знает, что это такое.

Регулярные выражения - это набор специальных символов, которые позволяют искать в каком-нибудь тексте похожие выражения. Думаю, все вы пользовались комбинацией клавишь Ctr + F для поиска чего-нибудь в документе. Так вот это был поиск точных совпадений. А регулярные выражения умеют искать не только точные совпадения, но и совпадения в тексте, соответствующие определённому шаблону.

Например: вы хотите найти все числа в тексте. Или все слова, заканчивающиеся на согласную букву. Или все слова, которые начинаются с большой буквы. Или все слова, перед которыми стоит какое-нибудь число. Можно придумать сотни примеров, где можно таким образом использовать регулярные выражения. Общее тут то, что они позволяют найти кусок текста, соответствующий заданному шаблону.

Где они используются? Ну во-первых, они встроены в современные текстовые редакторы для написания кода и таким образом можно найти и заменять в тексте что угодно на что-то-то другое по вашему шаблону. Они используются для тех же целей во многих Unix-утилитах - например, grep или sed. Их поддерживают большинство современных языков программирования, и регулярные выражения можно использовать в вашем коде.

Синтаксис регулярных выражений имеет разные стандарты, и может незначительно отличаться в разных языках программирования и в консольных утилитах, поэтому чтобы не ошибиться наверняка, обращайтесь к документации того инструмента, которым вы сейчас пользуетесь.

Я же для начала расскажу о некоторых самых распространённых специальных символах, используемых в регулярных выражениях.

. (точка) - означает любой символ (букву, знак пунктуации, пробел или перенос строки). Например, регулярное выражение «к.т» найдёт в тексте слова «кот», «кит», «кiт», «к8т».

\n - означает новую строку

[] (квадратные скобки) позволяют указать, что в тексте встречается один из символов, указанных внутри скобок. Например, «к[ои]т» позволит нам найти все слова «кот» и «кит» в тексте.

Также есть символы, указывающие, сколько раз в шаблоне может повторяться какой-либо символ (или набор символов).

* (звёздочка) - означает «сколько угодно повторений символа, стоящего перед ней». Сколько угодно, включая ноль. Например, возьмём регулярное выражение «кот!*». Оно означает, что мы ищем строку «кот» + какое угодно число восклицательных знаков после неё. Нам подойдут такие случаи, как «кот» (ноль знаков !), «кот!», «кот!!!!» и так далее.

+ (плюс) - похож на звёздочку, он означает сколько угодно повторений символа, но не менее 1 раза. «кот!+» - уже не найдёт строку «кот», так как в ней нет восклицательного знака.

? - означает, что какой-то символ встречается либо 0, либо 1 раз. Например, «https?::» - найдёт нам в тексте и «http::» и «https::».

Специальные символы можно комбинировать. Например, «к[ои]+т» - означает, один или более символов, указанных в скобках. Этот шаблон найдёт слова «кот», «кооот», «кит», «киоооит».

Это лишь небольшая часть символов, которые используются в регулярных выражениях, рассказала я о них для того, чтобы вы не боялись этой темы и дальше продолжили изучать её самостоятельно.

Главное - никогда не пытайтесь парсить html с помощью регулярных выражений.

Вот пример поиска совпадений в тексте с помощью регулярных выражений в текстовом редакторе Visual Studio Code

Чему не научат на курсах

Знаете, что меня удивляет?

С одной стороны, всегда были и есть люди, которые нашли сами какие-то книги по тому же программированию, сами прочитали, сами попробовали все примеры из книги. Сами нагуглили всю нужную информацию, почитали документацию, сделали какие-то свои проекты - игру написали, сайт для личного пользования создали. Ну и в итоге устроились работать по новоприобретённой специальности.

С другой стороны, есть курсы, пусть и недешевые, в которых есть масса всего, что, казалось бы, должно сильно облегчить задачу стать айтишником. Там есть и преподаватели, и ментор, которому можно задать вопрос, и какие-то чаты и форумы для поддержки, и домашние задания, которые для вас проверяют и дают комментарии, и код-ревью, там придуман проект для тренировки навыков. Составлено расписание на год вперёд, куда собрали всё, что должно потребоваться в первую очередь. В общем, казалось бы, масса работы проделана за учащихся, и всё это должно ускорить и облегчить процесс обучения.

Да, понятно, что курс может быть составлен не идеально, преподаватель объясняет непонятно, задания плохо сформулированы, расписание кривое, и ещё куча всевозможных косяков. Но тем не менее, по сравнению с самостоятельным обучением - в обнимку с книжками, курсы дают множество возможностей - возможность задавать вопросы, возможность потренироваться на учебных заданиях, возможность получать обратную связь от преподавателя, возможность узнать о своих ошибках на ранней стадии.

Но почему же потом возникают очень разочарованные отзывы? Понятно, что в первую очередь из-за высокой цены и радужных обещаний маркетологов о таких курсах.

Но еще и потому, что никакие курсы не научат вас мотивации, целеустремлённости, усердию, любознательности и глубокому интересу к предметной области. Ровно эти качества есть у тех людей, которые учатся абсолютно сами и справляются с задачей. Но часто этого всего не хватает тем, кто возлагает слишком большие ожидания на платные курсы, и слишком мало значения придаёт своим собственным усилиям и заинтересованности.

Мои подписчики любят метафоры, поэтому приведу вам такой пример.

Обычная школа, урок биологии, и два ученика. Первый - послушал учителя, не совсем понял материал, сделал кое-как домашнее задание, всё ещё не до конца понимая, о чём речь, так же написал контрольную и получил свою оценку.

Другой ученик - послушал как учитель рассказывает о генетике и экспериментах Менделя по скрещиванию сортов гороха и думает - «Интересно! Я хочу глубже разобраться в этой теме». Дома он погуглил ещё об экспериментах Менделя, почитал кое-какие статьи (да хотя бы википедию), пошел в магазин и купил несколько сортов гороха, чтобы повторить эксперимент. Ну в общем, вы поняли идею, да?

Какой из двух учеников станет успешным ̶п̶р̶о̶г̶р̶а̶м̶м̶и̶с̶т̶о̶м̶ биологом, а какой будет говорить: «ой, у нас в школе такая слабая биология была, я вообще ничего не понял! И учитель абы как объяснял, ужасное у нас образование!».