ООП
Для тех, кто присоединился недавно, ввожу в курс дела: многие подписчики жаловались мне, что начали изучать программирование, но не смогли разобраться с такой темой как ООП (объектно-ориентированное программирование).
Поэтому я начала серию постов про ООП, где разбираем на пальцах и максимально простыми словами основные понятия.
Кто не читал предыдущие посты из этой серии, рекомендую начать с них:
- Что такое классы
- Что такое экземпляры классов, и как их создавать
Сегодня же разберёмся с самим понятием «объектно-ориентированное программирование».
Собственно ООП - это подход к программированию, основанный на использовании классов и экземпляров этих классов. У этого подхода есть ряд принципов, о которых я расскажу подробнее в дальнейшем (абстракция, инкапсуляция, наследование, полиморфизм).
В языках программирования, которые поддерживают ООП всегда присутствуют классы. Например, в Java обойтись без классов вообще невозможно. C++ также придуман специально для ООП, но в нём при желании можно и не пользоваться классами. Но помните, что это своего рода моветон - по-хорошему, если вы не используете классы и ООП, значит нужно писать на языке Си, а не C++.
А есть языки, которые поддерживают ООП, но позволяют обходиться и без него. Например, такой язык - Python. Причем, ООП в Python специфический: там есть классы, но принципы ООП там можно не соблюдать (синтаксис языка это никак не ограничивает). Так что по сути это ООП, основанное на джентельменских соглашениях, то есть на надежде, что программисты сами добровольно не будут их нарушать.
Есть языки, в которых вообще нет ни классов, ни ООП. Например, языки C и Go.
А есть и вовсе функциональные языки - в них, если несколько упрощать, никакие промежуточные объекты не используются, а результаты вычислений передаются из одной функции в другую по цепочке, пока не будет получен нужный результат - это Lisp, Haskell и другие.
Подробнее принципы ООП (абстракция, инкапсуляция, наследование, полиморфизм) - разберем в следующих постах.
Задать вопрос автору блога можно здесь: @hum_it_bot
Для тех, кто присоединился недавно, ввожу в курс дела: многие подписчики жаловались мне, что начали изучать программирование, но не смогли разобраться с такой темой как ООП (объектно-ориентированное программирование).
Поэтому я начала серию постов про ООП, где разбираем на пальцах и максимально простыми словами основные понятия.
Кто не читал предыдущие посты из этой серии, рекомендую начать с них:
- Что такое классы
- Что такое экземпляры классов, и как их создавать
Сегодня же разберёмся с самим понятием «объектно-ориентированное программирование».
Собственно ООП - это подход к программированию, основанный на использовании классов и экземпляров этих классов. У этого подхода есть ряд принципов, о которых я расскажу подробнее в дальнейшем (абстракция, инкапсуляция, наследование, полиморфизм).
В языках программирования, которые поддерживают ООП всегда присутствуют классы. Например, в Java обойтись без классов вообще невозможно. C++ также придуман специально для ООП, но в нём при желании можно и не пользоваться классами. Но помните, что это своего рода моветон - по-хорошему, если вы не используете классы и ООП, значит нужно писать на языке Си, а не C++.
А есть языки, которые поддерживают ООП, но позволяют обходиться и без него. Например, такой язык - Python. Причем, ООП в Python специфический: там есть классы, но принципы ООП там можно не соблюдать (синтаксис языка это никак не ограничивает). Так что по сути это ООП, основанное на джентельменских соглашениях, то есть на надежде, что программисты сами добровольно не будут их нарушать.
Есть языки, в которых вообще нет ни классов, ни ООП. Например, языки C и Go.
А есть и вовсе функциональные языки - в них, если несколько упрощать, никакие промежуточные объекты не используются, а результаты вычислений передаются из одной функции в другую по цепочке, пока не будет получен нужный результат - это Lisp, Haskell и другие.
Подробнее принципы ООП (абстракция, инкапсуляция, наследование, полиморфизм) - разберем в следующих постах.
Задать вопрос автору блога можно здесь: @hum_it_bot
Никаких лавров
Еще меня часто спрашивают: каково это - работать в IT с гуманитарным образованием? Как ко мне относятся коллеги? Нет ли пренебрежительного отношения?
И знаете, поначалу это даже было слегка обидно, но всем пофиг. Назвался груздем - полезай в кузов. Назвалась программистом - пиши код. Относятся ровно так же, как и к любому другому коллеге - хоть он закончил Бауманку, хоть учился сам по книгам. В IT важно только что ты знаешь, и что умеешь. Всё. Более того, никто даже не помнит, какое у меня там образование и кем я работала раньше - после собеседования эта информация моментально забывается, как не имеющая никакого значения.
Изначально я, грешным делом, надеялась на какие-то лавры. Думала, что очень круто так сменить профессию, и что кто-то (ну хоть кто-то) это оценит и заметит. Но - никаких лавров я не получила. Родители не особо поняли, что в этом такого прикольного (лучше бы детей рожала). Для друзей не айтишников всё это наше IT - просто какие-то незнакомые слова, которые им ни о чем не говорят. А коллеги? А для коллег я с самого начала была просто одной из них - никто даже не обратил внимание, что я вроде как (бывший?) гуманитарий (или бывших не бывает?).
Моя награда была иной - интересная работа и гораздо более привлекательная зарплата, чем до этого.
Но, с другой стороны, это ведь и не такое уж большое дело - научиться чему-то новому. Все мы способны учиться, на то мы и Homo Sapience.
Еще меня часто спрашивают: каково это - работать в IT с гуманитарным образованием? Как ко мне относятся коллеги? Нет ли пренебрежительного отношения?
И знаете, поначалу это даже было слегка обидно, но всем пофиг. Назвался груздем - полезай в кузов. Назвалась программистом - пиши код. Относятся ровно так же, как и к любому другому коллеге - хоть он закончил Бауманку, хоть учился сам по книгам. В IT важно только что ты знаешь, и что умеешь. Всё. Более того, никто даже не помнит, какое у меня там образование и кем я работала раньше - после собеседования эта информация моментально забывается, как не имеющая никакого значения.
Изначально я, грешным делом, надеялась на какие-то лавры. Думала, что очень круто так сменить профессию, и что кто-то (ну хоть кто-то) это оценит и заметит. Но - никаких лавров я не получила. Родители не особо поняли, что в этом такого прикольного (лучше бы детей рожала). Для друзей не айтишников всё это наше IT - просто какие-то незнакомые слова, которые им ни о чем не говорят. А коллеги? А для коллег я с самого начала была просто одной из них - никто даже не обратил внимание, что я вроде как (бывший?) гуманитарий (или бывших не бывает?).
Моя награда была иной - интересная работа и гораздо более привлекательная зарплата, чем до этого.
Но, с другой стороны, это ведь и не такое уж большое дело - научиться чему-то новому. Все мы способны учиться, на то мы и Homo Sapience.
Баги мышления
Сегодня хочу поговорить об установках, которые мешают вам (нам) развиваться: и в IT, и не только.
Если что, у себя я их тоже замечаю, так что не расстраивайтесь.
Баг 1: Я ещё не готов. Думаю, эта «истина» закладывается нашей системой образования: возникает ощущение, что прежде, чем начать что-то делать, нужно долго-долго учиться, учиться и еще раз учиться. Сначала «отсиди» 5-6 лет в ВУЗе - и вот только тогда «начинай начинать». И поэтому у многих новичков появляется почти неистребимая установка: я ещё не готов. Написать свою небольшую програмку? - Ещё не готов. Вот закончу курсы, прочитаю еще 10 книг, позанимаюсь с репетитором - тогда и начну писать. Поучаствовать в опен-сорс проекте? - Нет, я еще не готов. Записаться на хакатон - я еще не готов. Устроиться на какую-нибудь стажировку? - Ну что вы, я еще совсем ничего не знаю. Сходить на собеседование? - Нет, я не готов.
Я сама долгое время так не могла написать резюме и начать искать работу, потому что «ну я же совсем ничего не знаю» - а как написала, взяли на работу с первого же собеседования.
В чём недостаток этого подхода? Теоретические знания, безусловно важны и без книг и/или курсов айтишнику не обойтись. Но не менее важна практика - и начать приобретать её лучше как можно раньше, параллельно с изучением теории. Если вы умеете написать уже несколько строчек кода - значит пришло время писать небольшие программы (а может, и программы побольше). Невозможно «подготовиться» к программированию только за счет изучения теории (пусть даже с учебными примерами). А самая лучшая практика приобретается на работе.
Представьте, что вы хотите кататься на коньках, но на лед выходить не решаетесь - годами читаете книги про конькобежный спорт, смотрите видосики, отрабатываете движения в воздухе. Научитесь вы так кататься? «На лёд» нужно выходить как можно раньше, не взращивайте в себе вечного студента.
Баг 2: Не умеешь - не берись. Как только вы сталкиваетесь с чем-то незнакомым, это вызывает страх, и вы стараетесь избежать новой темы. Тут срабатывает школьный шаблон «это мы не проходили, это нам не задавали». Например, вы работаете с Java, а тут вам (в процессе учебы или на работе) подворачивается код на Python. И реакция: «Нее, это незнакомый язык, я его не изучал, не буду даже на него смотреть». Срабатывает баг из предыдущего абзаца - мол прежде чем что-то делать, нужно это хорошенько изучить. «Нельзя просто взять Python и начать на нём кодить - сначала нужно книжку хотя бы прочитать.» Так вот ничего подобного - не только можно, но и нужно. Когда вы встречаете что-то незнакомое и непонятное, нужно не избегать этого, а считать, что это ОТЛИЧНЫЙ ШАНС ПОЗНАКОМИТЬСЯ С PYTHON. Гугл в помощь и вперёд.
Когда я устроилась на первую работу Python-разработчиком, мне почти сразу дали код на C# - так я начала кодить на C#. Когда я устроилась в другое место как бэкенд-разработчик на Python, одной из первых моих задач было - написать фронт на JavaScript. Не бойтесь вы нового - в Интернете есть информация обо всём, для всего есть документация в открытом доступе, а языки все плюс-минус похожи друг на друга. Если вы катались на коньках, значит сможете стать и на ролики.
Баг 3: Синдром самозванца. «Да я тут вообще ничего не понимаю, все коллеги умные и всё знают, а я тупой, и скоро они догадаются и уволят меня.» В результате стесняешься задавать вопросы, так как считаешь, что вопросы тупые и боишься опозориться. Не признаёшься, что не понял свою задачу - а то тебя так точно раскроют, Штирлиц ты наш. Молчишь на совещаниях и не участвуешь в обсуждениях - а что ты можешь сказать, ты же тупее здесь всех остальных? Если не согласен с чем-то - не высказываешься - другим-то виднее, наверно ты ошибся. В общем, детский сад, старайтесь не делать так. Даже если чего-то не понимаете, нужно вести себя как взрослый и общаться как взрослый, а не как школьник, который скрывает, что прогулял урок. Если вы узнали себя в этом описании, и вообще по натуре вы - скромный молчун - работайте над собой.
Не бойтесь начинать и не бойтесь ошибаться. Никто не рождается программистом.
Сегодня хочу поговорить об установках, которые мешают вам (нам) развиваться: и в IT, и не только.
Если что, у себя я их тоже замечаю, так что не расстраивайтесь.
Баг 1: Я ещё не готов. Думаю, эта «истина» закладывается нашей системой образования: возникает ощущение, что прежде, чем начать что-то делать, нужно долго-долго учиться, учиться и еще раз учиться. Сначала «отсиди» 5-6 лет в ВУЗе - и вот только тогда «начинай начинать». И поэтому у многих новичков появляется почти неистребимая установка: я ещё не готов. Написать свою небольшую програмку? - Ещё не готов. Вот закончу курсы, прочитаю еще 10 книг, позанимаюсь с репетитором - тогда и начну писать. Поучаствовать в опен-сорс проекте? - Нет, я еще не готов. Записаться на хакатон - я еще не готов. Устроиться на какую-нибудь стажировку? - Ну что вы, я еще совсем ничего не знаю. Сходить на собеседование? - Нет, я не готов.
Я сама долгое время так не могла написать резюме и начать искать работу, потому что «ну я же совсем ничего не знаю» - а как написала, взяли на работу с первого же собеседования.
В чём недостаток этого подхода? Теоретические знания, безусловно важны и без книг и/или курсов айтишнику не обойтись. Но не менее важна практика - и начать приобретать её лучше как можно раньше, параллельно с изучением теории. Если вы умеете написать уже несколько строчек кода - значит пришло время писать небольшие программы (а может, и программы побольше). Невозможно «подготовиться» к программированию только за счет изучения теории (пусть даже с учебными примерами). А самая лучшая практика приобретается на работе.
Представьте, что вы хотите кататься на коньках, но на лед выходить не решаетесь - годами читаете книги про конькобежный спорт, смотрите видосики, отрабатываете движения в воздухе. Научитесь вы так кататься? «На лёд» нужно выходить как можно раньше, не взращивайте в себе вечного студента.
Баг 2: Не умеешь - не берись. Как только вы сталкиваетесь с чем-то незнакомым, это вызывает страх, и вы стараетесь избежать новой темы. Тут срабатывает школьный шаблон «это мы не проходили, это нам не задавали». Например, вы работаете с Java, а тут вам (в процессе учебы или на работе) подворачивается код на Python. И реакция: «Нее, это незнакомый язык, я его не изучал, не буду даже на него смотреть». Срабатывает баг из предыдущего абзаца - мол прежде чем что-то делать, нужно это хорошенько изучить. «Нельзя просто взять Python и начать на нём кодить - сначала нужно книжку хотя бы прочитать.» Так вот ничего подобного - не только можно, но и нужно. Когда вы встречаете что-то незнакомое и непонятное, нужно не избегать этого, а считать, что это ОТЛИЧНЫЙ ШАНС ПОЗНАКОМИТЬСЯ С PYTHON. Гугл в помощь и вперёд.
Когда я устроилась на первую работу Python-разработчиком, мне почти сразу дали код на C# - так я начала кодить на C#. Когда я устроилась в другое место как бэкенд-разработчик на Python, одной из первых моих задач было - написать фронт на JavaScript. Не бойтесь вы нового - в Интернете есть информация обо всём, для всего есть документация в открытом доступе, а языки все плюс-минус похожи друг на друга. Если вы катались на коньках, значит сможете стать и на ролики.
Баг 3: Синдром самозванца. «Да я тут вообще ничего не понимаю, все коллеги умные и всё знают, а я тупой, и скоро они догадаются и уволят меня.» В результате стесняешься задавать вопросы, так как считаешь, что вопросы тупые и боишься опозориться. Не признаёшься, что не понял свою задачу - а то тебя так точно раскроют, Штирлиц ты наш. Молчишь на совещаниях и не участвуешь в обсуждениях - а что ты можешь сказать, ты же тупее здесь всех остальных? Если не согласен с чем-то - не высказываешься - другим-то виднее, наверно ты ошибся. В общем, детский сад, старайтесь не делать так. Даже если чего-то не понимаете, нужно вести себя как взрослый и общаться как взрослый, а не как школьник, который скрывает, что прогулял урок. Если вы узнали себя в этом описании, и вообще по натуре вы - скромный молчун - работайте над собой.
Не бойтесь начинать и не бойтесь ошибаться. Никто не рождается программистом.
Почему с новичками сложно работать
Устроиться впервые на работу стажером или джуном - это челлендж.
Но, поверьте, трудно приходится не только вам - появление на работе начинающего сотрудника - это всегда нагрузка на руководителя и на более опытных коллег.
Вчера обсуждали с коллегой-руководителем отдела, какие качества новичков сильнее всего усложняют нам жизнь. Разумеется, не все джуны такие, мы рассматриваем самые тяжелые случаи:
- Безынициативность. Человек следует кредо «сижу и не высовываюсь». В обсуждениях (по рабочим вопросам) не участвует, сидит молчит (или хуже того, витает в облаках), свое мнение никогда не выражает, ничего не предлагает, не оспаривает, не генерит никаких идей. Пока его не растормошишь - не пошевелится. Делает только самый необходимый минимум.
- Безответственность. Когда человек берёт задачу, мы ожидаем, что он а) до конца понимает, о чём она б) уложится в сроки, как обещает в) если возникают непредвиденные проблемы и в сроки нельзя уложиться - сразу об этом сообщит. Что же мы имеем на практике? Сотрудник клянётся, что понял задачу, и что никаких вопросов у него нет, когда он на самом деле ничего не понял. Обещает сделать задачу за неделю, в итоге через неделю там и 10% не сделано и заранее об этом он не предупреждает. Либо же в процессе работы появились неожиданные препятствия, и вместо того, чтобы об этом рассказать и обсудить с коллегами, как действовать дальше - он просто сидит и молчит.
- Нежелание налаживать связи с другими коллегами (кроме необходимых). В процессе работы часто возникают вопросы, которые очень желательно обсудить с другими коллегами - с сотрудником другого отдела, с системным администратором, с менеджером другой команды. А некоторые джуны максимально избегают какого-либо общения с другими людьми. Если есть возможность не подходить к другому коллеге и не разговаривать с ним - он её не упустит.
- Изоляция в рамках своих задач. Когда вы приходите работать в команду, у команды, как правило, есть общие проекты и общие задачи, над которыми они работают сообща. Коллеги чаще всего плюс-минус в контексте работы друг друга и при необходимости моугут друг друга заменить. Джуны же часто готовы думать только о своём маленьком кусочке работы и совершенно игнорировать, что происходит вокруг - не вникать в задачи коллег, не интересоваться проектом в общем, не перенимать опыт
- Нежелание осваивать новые технологии, учиться у коллег. Как правило, когда вы устраиваетесь на работу, ваш стэк изначально меньше, чем требуется, и берут вас с расчётом, что вы в процессе работы освоите всё остальное. Некоторые джуны демонстрируют прямо воинственное нежелание осваивать новый стэк: не хочу, не могу, не буду.
- Неумение думать с позиции бизнеса. Если вы пришли в коммерческую разработку, значит, вы работаете для того, чтобы решать задачи бизнеса - грубо говоря, помогать ему зарабатывать деньги (иначе откуда он будет платить вам зарплату?). Начинающие сотрудники часто не видят связи между своей работой и глобальными целями компании. Поэтому прежде чем делать задачу, нужно всегда задавать вопрос: «а какую задачу бизнеса мы решаем?». И предлагать решение уже с учетом этой информации. Может оказаться, что то, что мы собирались сделать, на самом деле - плохая идея, так как есть возможность решить ту же задачу бизнеса куда более эффективно и с меньшими трудозатратами.
Вот почему такие джуны отнимают у нас максимум рабочего времени. Их нужно все время тормошить, чтобы они не молчали и активнее участвовали в работе команды. Их нужно по сто раз переспрашивать, правильно ли они поняли задачу, а потом регулярно проверять, есть ли прогресс, и не возникло ли каких-то препятствий, уточнять, укладываемся ли мы в срок. Их нужно водить за руку по всему офису и заставлять обсуждать рабочие вопросы с другими коллегами. Их нужно погружать в контекст работы команды и обучать.
И хорошо, если сотрудник в итоге адаптируется и становится самостоятельным. Некоторые джуны остаются такими и через год работы - вот тогда это проблема. Поэтому некоторые компании вообще не нанимают джуниор-разработчиков.
Устроиться впервые на работу стажером или джуном - это челлендж.
Но, поверьте, трудно приходится не только вам - появление на работе начинающего сотрудника - это всегда нагрузка на руководителя и на более опытных коллег.
Вчера обсуждали с коллегой-руководителем отдела, какие качества новичков сильнее всего усложняют нам жизнь. Разумеется, не все джуны такие, мы рассматриваем самые тяжелые случаи:
- Безынициативность. Человек следует кредо «сижу и не высовываюсь». В обсуждениях (по рабочим вопросам) не участвует, сидит молчит (или хуже того, витает в облаках), свое мнение никогда не выражает, ничего не предлагает, не оспаривает, не генерит никаких идей. Пока его не растормошишь - не пошевелится. Делает только самый необходимый минимум.
- Безответственность. Когда человек берёт задачу, мы ожидаем, что он а) до конца понимает, о чём она б) уложится в сроки, как обещает в) если возникают непредвиденные проблемы и в сроки нельзя уложиться - сразу об этом сообщит. Что же мы имеем на практике? Сотрудник клянётся, что понял задачу, и что никаких вопросов у него нет, когда он на самом деле ничего не понял. Обещает сделать задачу за неделю, в итоге через неделю там и 10% не сделано и заранее об этом он не предупреждает. Либо же в процессе работы появились неожиданные препятствия, и вместо того, чтобы об этом рассказать и обсудить с коллегами, как действовать дальше - он просто сидит и молчит.
- Нежелание налаживать связи с другими коллегами (кроме необходимых). В процессе работы часто возникают вопросы, которые очень желательно обсудить с другими коллегами - с сотрудником другого отдела, с системным администратором, с менеджером другой команды. А некоторые джуны максимально избегают какого-либо общения с другими людьми. Если есть возможность не подходить к другому коллеге и не разговаривать с ним - он её не упустит.
- Изоляция в рамках своих задач. Когда вы приходите работать в команду, у команды, как правило, есть общие проекты и общие задачи, над которыми они работают сообща. Коллеги чаще всего плюс-минус в контексте работы друг друга и при необходимости моугут друг друга заменить. Джуны же часто готовы думать только о своём маленьком кусочке работы и совершенно игнорировать, что происходит вокруг - не вникать в задачи коллег, не интересоваться проектом в общем, не перенимать опыт
- Нежелание осваивать новые технологии, учиться у коллег. Как правило, когда вы устраиваетесь на работу, ваш стэк изначально меньше, чем требуется, и берут вас с расчётом, что вы в процессе работы освоите всё остальное. Некоторые джуны демонстрируют прямо воинственное нежелание осваивать новый стэк: не хочу, не могу, не буду.
- Неумение думать с позиции бизнеса. Если вы пришли в коммерческую разработку, значит, вы работаете для того, чтобы решать задачи бизнеса - грубо говоря, помогать ему зарабатывать деньги (иначе откуда он будет платить вам зарплату?). Начинающие сотрудники часто не видят связи между своей работой и глобальными целями компании. Поэтому прежде чем делать задачу, нужно всегда задавать вопрос: «а какую задачу бизнеса мы решаем?». И предлагать решение уже с учетом этой информации. Может оказаться, что то, что мы собирались сделать, на самом деле - плохая идея, так как есть возможность решить ту же задачу бизнеса куда более эффективно и с меньшими трудозатратами.
Вот почему такие джуны отнимают у нас максимум рабочего времени. Их нужно все время тормошить, чтобы они не молчали и активнее участвовали в работе команды. Их нужно по сто раз переспрашивать, правильно ли они поняли задачу, а потом регулярно проверять, есть ли прогресс, и не возникло ли каких-то препятствий, уточнять, укладываемся ли мы в срок. Их нужно водить за руку по всему офису и заставлять обсуждать рабочие вопросы с другими коллегами. Их нужно погружать в контекст работы команды и обучать.
И хорошо, если сотрудник в итоге адаптируется и становится самостоятельным. Некоторые джуны остаются такими и через год работы - вот тогда это проблема. Поэтому некоторые компании вообще не нанимают джуниор-разработчиков.
#вашивопросы
Как найти работу джуниор разработчика если рабочего опыта в этой сфере нет, но я занимаюсь самостоятельным изучением? Училась на другом направлении в Германии, но поняла что это для меня скучно и неинтересно и я хочу в айти и постоянно учиться новому.
Сейчас я в России, в германии после провала на собеседовании упала мотивация.
Я слышала мнение от ребят, живущих в Европе, что в Германии найти работу новичку гораздо сложнее, чем в России.
Поэтому, раз вы сейчас находитесь в России - начните искать работу здесь. Заполните резюме, откликайтесь на всевозможные вакансии стажеров и джунов, ходите на собеседования.
В моем понимании, джун - это и есть человек без опыта (либо с минимальным опытом), и эта вакансия для того и придумана, чтобы человек набирался опыта, а человек с опытом - это уже не джун.
Тут я писала о том, почему не нужно бояться провальных собеседований и как извлечь из них пользу.
Начинающим специалистам, которые не прошли собеседования, мы с коллегами часто предлагаем подтянуть нужные темы, и вернуться к нам еще раз, скажем, через пару месяцев - вы тоже спрашивайте после неудачных собеседований о такой опции.
К слову - один из моих начальников как-то (уже имея солидный опыт за плечами) искал работу, и побывал на 10 собеседованиях, прежде чем ему сделали оффер - поначалу везде отказывали. Я же, к примеру, с нулевым опытом нашла работу с первой попытки - так что бывает по-разному, и главное - не сдаваться.
Лучший способ приобрести опыт - это найти первое место работы.
Еще вашу привлекательность в глазах работодателей можно поднять, выполняя какие-то проекты для себя (напишите сайт, игру, приложение, телеграм-бота итд) - чтобы потом рассказать о них на собеседовании. И еще можно включиться в какой-нибудь open source проект в качестве разработчика.
Но для начала поищите работу.
Нужна помощь. Так как я гуманитарий, большинство объяснений по коду приходится изучат тв стиле "Вот есть класс Кофе машины. Кофеварка - объект этого класса...". Проблема в том, что такие объяснения встречаются раз в 20 минут и то чисто как "Ну смотрите...". Есть ли какие то сайты/каналы, где прога сразу объясняется на таких "кофеварках" и эффективен ли такой метод обучения?
То, что вы описываете - это скорее наглядно-образное мышление - мышление основанное на конкретных примерах и образах, и гуманитарии тут не при чем.
Гуманитарные науки (как и программирование) тоже используют абстрактное мышление - поверьте, термины из философии, психологии или лингвистики «на кофемашинах» никто не объясняет.
Наглядно-образное мышление - это единственный вид мышления, доступный в полной мере детям дошкольного возраста, поэтому их обучают только в игровой форме, с использованием картинок и игрушек. В школе дети приобретают уже способность мыслить логически и использовать абстрактные понятия - поэтому после начальной школы в школьном материале уже все больше теоретических описаний, и меньше картинок и игрушек.
В обучении взрослых тоже используют конкретные примеры и иллюстрации, а также метафоры - но только ради того, чтобы они уловили общую закономерность, и могли использовать абстрактный термин.
Если вы хотите курсы, где больший упор делается на наглядно-образном мышлении - поищите курсы и книги для детей, возможно, стоит начать с них.
Но я бы рекомендовала развивать у себя абстрактное мышление, потому что и программирование основано на логике и абстракциях, и вообще любые другие области знаний тоже основаны на них. Вот нашла небольшую статью про абстрактное мышление и его развитие, может вам пригодится.
Задать вопрос автору блога можно здесь: @hum_it_bot
Как найти работу джуниор разработчика если рабочего опыта в этой сфере нет, но я занимаюсь самостоятельным изучением? Училась на другом направлении в Германии, но поняла что это для меня скучно и неинтересно и я хочу в айти и постоянно учиться новому.
Сейчас я в России, в германии после провала на собеседовании упала мотивация.
Я слышала мнение от ребят, живущих в Европе, что в Германии найти работу новичку гораздо сложнее, чем в России.
Поэтому, раз вы сейчас находитесь в России - начните искать работу здесь. Заполните резюме, откликайтесь на всевозможные вакансии стажеров и джунов, ходите на собеседования.
В моем понимании, джун - это и есть человек без опыта (либо с минимальным опытом), и эта вакансия для того и придумана, чтобы человек набирался опыта, а человек с опытом - это уже не джун.
Тут я писала о том, почему не нужно бояться провальных собеседований и как извлечь из них пользу.
Начинающим специалистам, которые не прошли собеседования, мы с коллегами часто предлагаем подтянуть нужные темы, и вернуться к нам еще раз, скажем, через пару месяцев - вы тоже спрашивайте после неудачных собеседований о такой опции.
К слову - один из моих начальников как-то (уже имея солидный опыт за плечами) искал работу, и побывал на 10 собеседованиях, прежде чем ему сделали оффер - поначалу везде отказывали. Я же, к примеру, с нулевым опытом нашла работу с первой попытки - так что бывает по-разному, и главное - не сдаваться.
Лучший способ приобрести опыт - это найти первое место работы.
Еще вашу привлекательность в глазах работодателей можно поднять, выполняя какие-то проекты для себя (напишите сайт, игру, приложение, телеграм-бота итд) - чтобы потом рассказать о них на собеседовании. И еще можно включиться в какой-нибудь open source проект в качестве разработчика.
Но для начала поищите работу.
Нужна помощь. Так как я гуманитарий, большинство объяснений по коду приходится изучат тв стиле "Вот есть класс Кофе машины. Кофеварка - объект этого класса...". Проблема в том, что такие объяснения встречаются раз в 20 минут и то чисто как "Ну смотрите...". Есть ли какие то сайты/каналы, где прога сразу объясняется на таких "кофеварках" и эффективен ли такой метод обучения?
То, что вы описываете - это скорее наглядно-образное мышление - мышление основанное на конкретных примерах и образах, и гуманитарии тут не при чем.
Гуманитарные науки (как и программирование) тоже используют абстрактное мышление - поверьте, термины из философии, психологии или лингвистики «на кофемашинах» никто не объясняет.
Наглядно-образное мышление - это единственный вид мышления, доступный в полной мере детям дошкольного возраста, поэтому их обучают только в игровой форме, с использованием картинок и игрушек. В школе дети приобретают уже способность мыслить логически и использовать абстрактные понятия - поэтому после начальной школы в школьном материале уже все больше теоретических описаний, и меньше картинок и игрушек.
В обучении взрослых тоже используют конкретные примеры и иллюстрации, а также метафоры - но только ради того, чтобы они уловили общую закономерность, и могли использовать абстрактный термин.
Если вы хотите курсы, где больший упор делается на наглядно-образном мышлении - поищите курсы и книги для детей, возможно, стоит начать с них.
Но я бы рекомендовала развивать у себя абстрактное мышление, потому что и программирование основано на логике и абстракциях, и вообще любые другие области знаний тоже основаны на них. Вот нашла небольшую статью про абстрактное мышление и его развитие, может вам пригодится.
Задать вопрос автору блога можно здесь: @hum_it_bot
Привет! После обучения на курсах при компании и стажировки наконец-то стала Junior Software Developer (спасибо вам за вдохновение и личный пример успеха). Вопрос такой: есть ли у вас полезные советы для джунов основанные на личном опыте?
Во-первых, поздравляем нашу читательницу, приятно слышать.
Самого вопроса я так или иначе постоянно касаюсь в канале, но давайте подытожим и соберём рекомендации для новичков в один список.
1. Проявляйте любознательность: вовлекайтесь в рабочие процессы, интересуйтесь, какими проектами ещё занимается компания, какие есть направления работы (кроме вашего), какие технологии используются, что делают другие коллеги.
2. Будьте активны и внимательны: на совещаниях и рабочих обсуждениях вникайте во всё, что говорят коллеги, старайтесь уловить суть, задавайте вопросы, когда что-то непонятно. Предлагайте свои идеи или выражайте сомнения, если они у вас есть.
3. Задавайте вопросы: когда что-то непонятно - не молчите и не стесняйтесь. Задавайте даже самые тупые (на ваш взгляд) вопросы - главное чтобы в голове всё прояснилось.
4. Убедитесь, что вы поняли задачу: если у вас нет полного и исчерпывающего понимания своей задачи - уточняйте и переспрашивайте до тех пор, пока всё будет понятно. Если вы уверены, что поняли задачу - переформулируйте её своими словами, чтобы убедиться, что ваш руководитель и вы одинаково её понимаете: «Я правильно понимаю, мне нужно сделать вот это вот в такие сроки, и это нужно для того, чтобы то и то?» - так вы избежите игры в «испорченный телефон».
5. Грамотно просите о помощи: тут нужен баланс - с одной стороны, вам нужно получить всю необходимую информацию, с другой стороны - ценить время ваших коллег.
Задача коллег - направить вас в верном направлении, а не сделать работу за вас. Прежде чем попросить о помощи, убедитесь, что вы сделали всё, чтобы найти решение самостоятельно: поищите ответ в гугле, в документации, опробуйте разные решения - и потом уже идите к коллеге за советом, заодно расскажете, что уже попробовали, и что именно не получилось.
Если у вас много-много вопросов - запишите их и попросите коллегу уделить вам полчаса времени, чтобы их задать. Не надо отрывать коллегу каждые 5 минут с очередным вопросом - иначе он весь день будет заниматься только вами.
6. Налаживайте связи: у других коллег в компании (у тех, с кем вы не работаете тесно вместе) есть ценная информация, знания или технические скиллы, а, возможно, рычаги давления или доступ к каким-то ресурсам. Полезно иметь возможность при случае обратиться к подходящему человеку.
7. Отвечайте за результаты своей работы: не обещайте того, чего не сможете сделать. Если не удалось верно оценить сроки работы или возникли непредвиденные препятствия - сразу сообщайте об этом старшим коллегам. Если где-то накосячили - что-то сломали, что-то случайно удалили - расскажите об этом коллегам, не скрывайте - скорее всего, они что-то придумают.
8. Будьте осторожны: используя, скажем, git, убедитесь, что понимаете, что за команду вы собираетесь выполнить - не затрите нужный код в репозитории. Если у вас есть доступ к продовой базе данных - помните - 7 раз SELECT - 1 раз UPDATE. Если делаете что-то в базе данных руками, перед каждым UPDATE или DELETE открывайте транзакцию (например, командой BEGIN;) - потом убедитесь, что не удалили и не изменили ничего лишнего - и если произошло что-то нежелательное - откатите изменения командой ROLLBACK;
9. Оценивайте ресурсы: если вы написали программу, которая должна обработать много-много данных - прежде, чем её запускать, оцените, сколько времени занимает её работа на небольшом кусочке этих данных - возможно, для того, чтобы обработать все нужные данные, ей понадобитс 10 миллионов лет - и значит нужно переделывать. Оценивайте, сколько памяти и CPU нужно вашим программам - не факт, что их столько есть в наличии.
10. Пишите тесты. Даже если этого от вас не требуют. Когда пишете код
- сразу думайте, как вы будете его тестировать.
11. Осваивайте незнакомые технологии.
Задать вопрос автору блога можно здесь: @hum_it_bot
Во-первых, поздравляем нашу читательницу, приятно слышать.
Самого вопроса я так или иначе постоянно касаюсь в канале, но давайте подытожим и соберём рекомендации для новичков в один список.
1. Проявляйте любознательность: вовлекайтесь в рабочие процессы, интересуйтесь, какими проектами ещё занимается компания, какие есть направления работы (кроме вашего), какие технологии используются, что делают другие коллеги.
2. Будьте активны и внимательны: на совещаниях и рабочих обсуждениях вникайте во всё, что говорят коллеги, старайтесь уловить суть, задавайте вопросы, когда что-то непонятно. Предлагайте свои идеи или выражайте сомнения, если они у вас есть.
3. Задавайте вопросы: когда что-то непонятно - не молчите и не стесняйтесь. Задавайте даже самые тупые (на ваш взгляд) вопросы - главное чтобы в голове всё прояснилось.
4. Убедитесь, что вы поняли задачу: если у вас нет полного и исчерпывающего понимания своей задачи - уточняйте и переспрашивайте до тех пор, пока всё будет понятно. Если вы уверены, что поняли задачу - переформулируйте её своими словами, чтобы убедиться, что ваш руководитель и вы одинаково её понимаете: «Я правильно понимаю, мне нужно сделать вот это вот в такие сроки, и это нужно для того, чтобы то и то?» - так вы избежите игры в «испорченный телефон».
5. Грамотно просите о помощи: тут нужен баланс - с одной стороны, вам нужно получить всю необходимую информацию, с другой стороны - ценить время ваших коллег.
Задача коллег - направить вас в верном направлении, а не сделать работу за вас. Прежде чем попросить о помощи, убедитесь, что вы сделали всё, чтобы найти решение самостоятельно: поищите ответ в гугле, в документации, опробуйте разные решения - и потом уже идите к коллеге за советом, заодно расскажете, что уже попробовали, и что именно не получилось.
Если у вас много-много вопросов - запишите их и попросите коллегу уделить вам полчаса времени, чтобы их задать. Не надо отрывать коллегу каждые 5 минут с очередным вопросом - иначе он весь день будет заниматься только вами.
6. Налаживайте связи: у других коллег в компании (у тех, с кем вы не работаете тесно вместе) есть ценная информация, знания или технические скиллы, а, возможно, рычаги давления или доступ к каким-то ресурсам. Полезно иметь возможность при случае обратиться к подходящему человеку.
7. Отвечайте за результаты своей работы: не обещайте того, чего не сможете сделать. Если не удалось верно оценить сроки работы или возникли непредвиденные препятствия - сразу сообщайте об этом старшим коллегам. Если где-то накосячили - что-то сломали, что-то случайно удалили - расскажите об этом коллегам, не скрывайте - скорее всего, они что-то придумают.
8. Будьте осторожны: используя, скажем, git, убедитесь, что понимаете, что за команду вы собираетесь выполнить - не затрите нужный код в репозитории. Если у вас есть доступ к продовой базе данных - помните - 7 раз SELECT - 1 раз UPDATE. Если делаете что-то в базе данных руками, перед каждым UPDATE или DELETE открывайте транзакцию (например, командой BEGIN;) - потом убедитесь, что не удалили и не изменили ничего лишнего - и если произошло что-то нежелательное - откатите изменения командой ROLLBACK;
9. Оценивайте ресурсы: если вы написали программу, которая должна обработать много-много данных - прежде, чем её запускать, оцените, сколько времени занимает её работа на небольшом кусочке этих данных - возможно, для того, чтобы обработать все нужные данные, ей понадобитс 10 миллионов лет - и значит нужно переделывать. Оценивайте, сколько памяти и CPU нужно вашим программам - не факт, что их столько есть в наличии.
10. Пишите тесты. Даже если этого от вас не требуют. Когда пишете код
- сразу думайте, как вы будете его тестировать.
11. Осваивайте незнакомые технологии.
Задать вопрос автору блога можно здесь: @hum_it_bot
#вашивопросы
Подскажите пожалуйста какие бесплатные онлайн курсы можно послушать сейчас? И для начального понимания программирования и для изучения английского языка?
Я бы не рекомендовала смешивать изучение программирования и английского языка - лучше выделять отдельные часы для каждого предмета, мозгу проще фокусироваться на 1 задаче, а не сразу на 2х. Вот если вы уже хорошо понимаете аудио на слух, тогда другое дело. (С другой стороны, технический английский не такой уж сложный, и терминов там не много, так что бояться его и избегать любых видео на английском тоже не стоит).
И второй момент, на который я обратила внимание в вашем вопросе - «послушать» курсы. Курсы важно не только слушать, но и выполнять практические задания и задачки на программирование. IT - это в первую очередь практика. Возможно, это я придираюсь к словам, и вы и не имели в виду, что собираетесь только слушать, но это у нас айтишников профдеформация такая - докапываться до смысла каждого слова.
А рекомендую всем я традиционно бесплатный гарвардский курс CS50 по введению в Computer Science и программирование. В этом посте все ссылки.
Задать вопрос автору блога можно будет здесь (когда телеграм починят): @hum_it_bot
Подскажите пожалуйста какие бесплатные онлайн курсы можно послушать сейчас? И для начального понимания программирования и для изучения английского языка?
Я бы не рекомендовала смешивать изучение программирования и английского языка - лучше выделять отдельные часы для каждого предмета, мозгу проще фокусироваться на 1 задаче, а не сразу на 2х. Вот если вы уже хорошо понимаете аудио на слух, тогда другое дело. (С другой стороны, технический английский не такой уж сложный, и терминов там не много, так что бояться его и избегать любых видео на английском тоже не стоит).
И второй момент, на который я обратила внимание в вашем вопросе - «послушать» курсы. Курсы важно не только слушать, но и выполнять практические задания и задачки на программирование. IT - это в первую очередь практика. Возможно, это я придираюсь к словам, и вы и не имели в виду, что собираетесь только слушать, но это у нас айтишников профдеформация такая - докапываться до смысла каждого слова.
А рекомендую всем я традиционно бесплатный гарвардский курс CS50 по введению в Computer Science и программирование. В этом посте все ссылки.
Задать вопрос автору блога можно будет здесь (когда телеграм починят): @hum_it_bot
#вашивопросы
Хочу войти в it сфера с абсолютного нуля. По началу заинтересовала тема геймдева, работа с движками, с ландшафтом или разработкой игр или фильмов (анимаций то, что можно делать использую игровые движки) Читал что это довольно перспективная сфера, в том числе работа с Led павильонами по типу тех где снимался сериал Мандалорец. Понятия не имею с чего начать и какие вопросы задавать. Очень много информацию и выбрать актуальную в данную момент сложно, был бы рад ответу на данный вопрос.
Итак, если я верно понимаю вопрос - вы хотите с чего-то начать, и не хотите самостоятельно искать информацию.
Тогда есть такие варианты:
1) Обеспечить себя общей айтишной базой, пройти бесплатный курс по введению в Computer Science - про CS50 я столько раз уже тут писала, что уже даже самой надоело. Так вы создадите себе бэкграунд, и уже не будете начинать с абсолютного нуля. Потом уже идти на узкоспециализированные курсы - скажем, по геймдеву
2) Cразу пойти на платные курсы по геймдеву - желательно на длительные (год-полтора), чтобы не искать информацию самостоятельно и не тонуть в её обилии.
- Разработка игр на Unity от Geekbrains (длительность около года)
- Разработка игр на Unreal Engine Geekbrains
- Профессия разработчик игр на Unity от Skillfactory (12 месяцев)
Есть и более ускоренные варианты - на несколько месяцев. Тут, очевидно, будут давать меньше материала и практики, но и по цене они обычно дешевле:
- Разработчик игр на Unity от Нетологии (7 месяцев)
- Разработчик игр на Unity за 6 месяцев от Geekbrains
3) Вариант для более самостоятельных: просто берёте любые понравившиеся курсы по разработке игр на недорогих платформах - и проходите любые из них, в любом порядке - главное начать, а потом уже сориентируетесь. На Udemy можно найти целый список курсов по теме, цена вопроса - 1000 рублей за курс (UPD 2022 - cейчас из-за санкций оплатить курсы студентам из России там нельзя).
4) Поскольку вы еще не определились, хотите ли вы в разработку или заниматься графикой - можно ещё рассмотреть профессии, связанные с дизайном спецэффектов - моушен-дизайн, 3D-графика, VFX. В этом посте была подборка курсов, где обучают этим профессиям.
Задать вопрос автору блога можно здесь: @hum_it_bot
Хочу войти в it сфера с абсолютного нуля. По началу заинтересовала тема геймдева, работа с движками, с ландшафтом или разработкой игр или фильмов (анимаций то, что можно делать использую игровые движки) Читал что это довольно перспективная сфера, в том числе работа с Led павильонами по типу тех где снимался сериал Мандалорец. Понятия не имею с чего начать и какие вопросы задавать. Очень много информацию и выбрать актуальную в данную момент сложно, был бы рад ответу на данный вопрос.
Итак, если я верно понимаю вопрос - вы хотите с чего-то начать, и не хотите самостоятельно искать информацию.
Тогда есть такие варианты:
1) Обеспечить себя общей айтишной базой, пройти бесплатный курс по введению в Computer Science - про CS50 я столько раз уже тут писала, что уже даже самой надоело. Так вы создадите себе бэкграунд, и уже не будете начинать с абсолютного нуля. Потом уже идти на узкоспециализированные курсы - скажем, по геймдеву
2) Cразу пойти на платные курсы по геймдеву - желательно на длительные (год-полтора), чтобы не искать информацию самостоятельно и не тонуть в её обилии.
- Разработка игр на Unity от Geekbrains (длительность около года)
- Разработка игр на Unreal Engine Geekbrains
- Профессия разработчик игр на Unity от Skillfactory (12 месяцев)
Есть и более ускоренные варианты - на несколько месяцев. Тут, очевидно, будут давать меньше материала и практики, но и по цене они обычно дешевле:
- Разработчик игр на Unity от Нетологии (7 месяцев)
- Разработчик игр на Unity за 6 месяцев от Geekbrains
3) Вариант для более самостоятельных: просто берёте любые понравившиеся курсы по разработке игр на недорогих платформах - и проходите любые из них, в любом порядке - главное начать, а потом уже сориентируетесь. На Udemy можно найти целый список курсов по теме, цена вопроса - 1000 рублей за курс (UPD 2022 - cейчас из-за санкций оплатить курсы студентам из России там нельзя).
4) Поскольку вы еще не определились, хотите ли вы в разработку или заниматься графикой - можно ещё рассмотреть профессии, связанные с дизайном спецэффектов - моушен-дизайн, 3D-графика, VFX. В этом посте была подборка курсов, где обучают этим профессиям.
Задать вопрос автору блога можно здесь: @hum_it_bot
Telegram
Программирование для гуманитариев
Товарищи, мои подписчики нашли ещё одну версию курса CS50 в переводе на русский язык.
Для тех, кто тут недавно и ещё не в курсе - это бесплатный гарвардский курс по введению в Computer Science, с которого я всем советую начинать знакомство с IT и программированием.…
Для тех, кто тут недавно и ещё не в курсе - это бесплатный гарвардский курс по введению в Computer Science, с которого я всем советую начинать знакомство с IT и программированием.…
#вашивопросы
Можете посоветовать необходимую базу (книги, курсы, технологии и пр.) чтобы при входе в сферу не только владеть определенными навыками (которые я изучу в онлайн университете, например), но и понимать больше и быть более профессиональным специалистом? Например тот, кто уже в вузе или школе стал интересоваться программированием и изучил разные направления явно сильнее чем тот, кто просто прошел курсы по определенному узкому стеку.
Например, пройти CS50, прочитать какие то базовые книги?
Или лучше не забивать себе голову этим сейчас и учить что то конкретное, а необходимые знания подтянутся в ходе работы?
Что касается технологий, в этом посте был список, который я рекомендую освоить ради общих знаний и крепкой базы (это точно пригодится при работе с бэкендом или при выполненении некоторых админских задач, да и просто для общего развития).
Более узкоспециализированные направления, такие как фротэнд или, скажем разработка под андроид я в расчёт не беру - у них есть свои дополнительные требования, и их я вам не смогу с ходу перечислить, так что если душа лежит к этим направлениям, поищите дополнительно список требований и по ним - наверняка, в сети кто-то уже написал. 🙂
Что касается эталонного списка книг или курсов - у меня такого нет. Отдельные любимые вещи я тут часто упоминаю (тот же cs50), но их немного. Я придерживаюсь мнения, что учиться можно по любым курсам и книгам - если даже попадется какой-то неудачный, это не так страшно - переходите к следующему, их ведь целый океан.
А голову лучше все же «забивать» прямо сейчас - потому что восполнять пробелы в фундаментальных знаниях во время работы будет сложно, времени и ресурсов может не хватить. Незнание основ может плохо сказаться на работе - будете принимать неверные решения, так как не учтете какой-то важный нюанс, про который как раз хорошо бы знать заранее.
Задать вопрос автору блога можно здесь: @hum_it_bot
Можете посоветовать необходимую базу (книги, курсы, технологии и пр.) чтобы при входе в сферу не только владеть определенными навыками (которые я изучу в онлайн университете, например), но и понимать больше и быть более профессиональным специалистом? Например тот, кто уже в вузе или школе стал интересоваться программированием и изучил разные направления явно сильнее чем тот, кто просто прошел курсы по определенному узкому стеку.
Например, пройти CS50, прочитать какие то базовые книги?
Или лучше не забивать себе голову этим сейчас и учить что то конкретное, а необходимые знания подтянутся в ходе работы?
Что касается технологий, в этом посте был список, который я рекомендую освоить ради общих знаний и крепкой базы (это точно пригодится при работе с бэкендом или при выполненении некоторых админских задач, да и просто для общего развития).
Более узкоспециализированные направления, такие как фротэнд или, скажем разработка под андроид я в расчёт не беру - у них есть свои дополнительные требования, и их я вам не смогу с ходу перечислить, так что если душа лежит к этим направлениям, поищите дополнительно список требований и по ним - наверняка, в сети кто-то уже написал. 🙂
Что касается эталонного списка книг или курсов - у меня такого нет. Отдельные любимые вещи я тут часто упоминаю (тот же cs50), но их немного. Я придерживаюсь мнения, что учиться можно по любым курсам и книгам - если даже попадется какой-то неудачный, это не так страшно - переходите к следующему, их ведь целый океан.
А голову лучше все же «забивать» прямо сейчас - потому что восполнять пробелы в фундаментальных знаниях во время работы будет сложно, времени и ресурсов может не хватить. Незнание основ может плохо сказаться на работе - будете принимать неверные решения, так как не учтете какой-то важный нюанс, про который как раз хорошо бы знать заранее.
Задать вопрос автору блога можно здесь: @hum_it_bot
#вашивопросы
Возможно ответ на мой вопрос уже был в канале, но я всё-таки дерзну спросить ещё.
Я совсем далек от айти сферы, работаю руками, и, возможно, меня сейчас закидают камнями идейные айтишники, но хочу изучить с целью увеличения заработка, не скажу, что меня тянет прям куда-то туда. Потому что я и не пробовал ничего ещё.
И вот решил углубиться и застопорился на этапе выбора специализации(фронтенд, девопс, бекэнд, датасайнс и т.д. и т.д.)
Как ты выбирала специфику, в которую углубилась, почему именно бекэнд?
Вопрос у меня вызывает чувство дежа вю, вероятно, что-то похожее уже было. Но мне ежедневно задают одни и те же вопросы, поэтому я уже смирилась с тем, что приходится повторяться в постах.
Специализацию я как таковую не выбирала. И метод обучения у меня был бессистемный - я просто изучала все подряд на coursera и edx. Курсов тогда там было не много, и около половины их тех, что я прошла были связаны с Python. Так что первую работу я искала - связанную с Python (а это так или иначе больше про бэкенд).
Первое место, где я работала - было в отделе Ops (это как DevOps, только без Dev) - отвечали мы за то, чтобы запускать в продакшен код, написанный разработчиками (из отдела Dev) и следить, чтобы всё работало как нужно. Мы настраивали графики с метриками, и следили по ним, что ничего не сломалось, реагировали на жалобы пользователей. Быстро чинили, когда что-то ломалось. Выкатывали в продакшен новые версии кода (и откатывали их, если возникали проблемы). Быстро делали хотфиксы, и чинили продакшен "по живому". Разработкой я там тоже занималась - но не 100% времени и не для критичный сервисов, также занималась поддержкой баз данных. Это была работа полу-админская, полу-разработческая, а потом я постепенно уходила в чистую разработку.
Дальше я ушла на вакансию разработчика - и опять-таки, мой бэкграунд (Python, базы данных итд) - был больше про бэкенд. Дальше работа строилась по методике DevOps - это значит, что нет разделения на Dev и Ops, как в предыдущей компании и разработчики отвечают не только за написание кода (dev), но и за деплоймент его на продакшен и за то, чтобы всё там работало. То есть это тот же мониторинг - графики, хотфиксы и поддержка сервисов - только на этот раз ты же сам и написал тот код, который поддерживаешь, а не отдел Dev, сидящий в другом кабинете.
Вот так я и стала бэкенд-разработчиком - не могу сказать, что я как-то осознанно выбирала направление, просто шла туда, где мои знания могли пригодиться.
Дата-саенс я пробовала изучать, уже работая разработчиком, но как-то забросила. К математике у меня не совсем лежит душа, мне больше нравится решать инженерные задачи - придумывать и создавать работающие приложения и сервисы.
А DevOps - это процесс, не человек, как любят у нас шутить. Человек, которого называют DevOps - это инженер, что-то среднее между администратором и разработчиком. Он отвечает за налаживание собственно DevOps как процесса. В частности, за настройку инфраструктуры, чтобы код, написанный разработчиком можно было одной кнопкой (а то и автоматически) отправлять на тестирование, на сборку, и затем - в продакшен, и также автоматически откатываться на предыдущую версию, если что-то прошло не так. Это у нас называется CI/CD - continuous integration, continuous delivery. Хороший и дорогостоящий девопс-инженер должен как свои пять пальцев знать, как работать с кучей технологий, но требования к конкретным технологиям разнятся в зависимости от того, что используется в компании. Например, если там всё сделано на основе Kubernetes - девопс должен быть экспертом по кубернетису.
И это всё же больше админская вакансия, чем разработческая, а я училась именно разработке.
Фронтэнд - ну.. не знаю. Задачи по фронту мне иногда приходится делать, но уходить с головой в один только фронтэнд как-то особо не хотелось. На бэке ведь столько всего интересного - и базы данных, и брокеры сообщений, и сервера и этот ваш ci/cd, и сети, чего там только нет.
Задать вопрос автору блога можно здесь: @hum_it_bot
Возможно ответ на мой вопрос уже был в канале, но я всё-таки дерзну спросить ещё.
Я совсем далек от айти сферы, работаю руками, и, возможно, меня сейчас закидают камнями идейные айтишники, но хочу изучить с целью увеличения заработка, не скажу, что меня тянет прям куда-то туда. Потому что я и не пробовал ничего ещё.
И вот решил углубиться и застопорился на этапе выбора специализации(фронтенд, девопс, бекэнд, датасайнс и т.д. и т.д.)
Как ты выбирала специфику, в которую углубилась, почему именно бекэнд?
Вопрос у меня вызывает чувство дежа вю, вероятно, что-то похожее уже было. Но мне ежедневно задают одни и те же вопросы, поэтому я уже смирилась с тем, что приходится повторяться в постах.
Специализацию я как таковую не выбирала. И метод обучения у меня был бессистемный - я просто изучала все подряд на coursera и edx. Курсов тогда там было не много, и около половины их тех, что я прошла были связаны с Python. Так что первую работу я искала - связанную с Python (а это так или иначе больше про бэкенд).
Первое место, где я работала - было в отделе Ops (это как DevOps, только без Dev) - отвечали мы за то, чтобы запускать в продакшен код, написанный разработчиками (из отдела Dev) и следить, чтобы всё работало как нужно. Мы настраивали графики с метриками, и следили по ним, что ничего не сломалось, реагировали на жалобы пользователей. Быстро чинили, когда что-то ломалось. Выкатывали в продакшен новые версии кода (и откатывали их, если возникали проблемы). Быстро делали хотфиксы, и чинили продакшен "по живому". Разработкой я там тоже занималась - но не 100% времени и не для критичный сервисов, также занималась поддержкой баз данных. Это была работа полу-админская, полу-разработческая, а потом я постепенно уходила в чистую разработку.
Дальше я ушла на вакансию разработчика - и опять-таки, мой бэкграунд (Python, базы данных итд) - был больше про бэкенд. Дальше работа строилась по методике DevOps - это значит, что нет разделения на Dev и Ops, как в предыдущей компании и разработчики отвечают не только за написание кода (dev), но и за деплоймент его на продакшен и за то, чтобы всё там работало. То есть это тот же мониторинг - графики, хотфиксы и поддержка сервисов - только на этот раз ты же сам и написал тот код, который поддерживаешь, а не отдел Dev, сидящий в другом кабинете.
Вот так я и стала бэкенд-разработчиком - не могу сказать, что я как-то осознанно выбирала направление, просто шла туда, где мои знания могли пригодиться.
Дата-саенс я пробовала изучать, уже работая разработчиком, но как-то забросила. К математике у меня не совсем лежит душа, мне больше нравится решать инженерные задачи - придумывать и создавать работающие приложения и сервисы.
А DevOps - это процесс, не человек, как любят у нас шутить. Человек, которого называют DevOps - это инженер, что-то среднее между администратором и разработчиком. Он отвечает за налаживание собственно DevOps как процесса. В частности, за настройку инфраструктуры, чтобы код, написанный разработчиком можно было одной кнопкой (а то и автоматически) отправлять на тестирование, на сборку, и затем - в продакшен, и также автоматически откатываться на предыдущую версию, если что-то прошло не так. Это у нас называется CI/CD - continuous integration, continuous delivery. Хороший и дорогостоящий девопс-инженер должен как свои пять пальцев знать, как работать с кучей технологий, но требования к конкретным технологиям разнятся в зависимости от того, что используется в компании. Например, если там всё сделано на основе Kubernetes - девопс должен быть экспертом по кубернетису.
И это всё же больше админская вакансия, чем разработческая, а я училась именно разработке.
Фронтэнд - ну.. не знаю. Задачи по фронту мне иногда приходится делать, но уходить с головой в один только фронтэнд как-то особо не хотелось. На бэке ведь столько всего интересного - и базы данных, и брокеры сообщений, и сервера и этот ваш ci/cd, и сети, чего там только нет.
Задать вопрос автору блога можно здесь: @hum_it_bot
#вашивопросы
Как гуманитарий - гуманитарию вопрос (по мотивам последнего поста). А можешь провести сравнения между "должностями" в IT и в какой-то более-менее всем понятной сфере (ну, например, из маркетинга/PR. Что-то типа - devops - это как начальник отдела маркетинга). Или в IT -это совсем по-другому?
Что там происходит в маркетинге, я понятия не имею, если честно, так что буду использовать другую метафору - блинчики.
Представим, что IT-компания - это кафешка с блинчиками.
Там есть повар - человек, который печет блинчики. Это программист, он делает продукт для пользователей, а программа, написанная им - это блинчик.
Есть электрик - его задача, чтобы в сети было электричество и плита работала, чтобы повар мог печь блинчики. Это системный администратор.
Есть тестировщик - он пробует готовый блинчик, а потом приносит его обратно повару (разработчику) и говорит: слишком солёный, надо переделать.
Если в компании не налажены процессы ci/cd (continuous integration, continuous delivery) - то есть непрерывный процесс доставки готового продукта конечному пользователю - кто-то должен приносить клиентам блинчики, то есть играть роль официанта. Например, это может делать сам повар - тогда ему придется тратить свое время еще и на обслуживание столов. Или это будут делать особые админы (Ops) - они тут как официанты, должны получать блинчики от ̶р̶а̶з̶р̶а̶б̶о̶т̶ч̶и̶к̶а̶, разносить их людям, следить, чтобы все столы обслуживались вовремя и качественно.
Сам процесс доставки блинчика потребителю называется деплоймент. Например, когда какой-нибудь сайт Вконтакте обновляет свою версию, и там появляются новые кнопки - значит разработчики выпустили новую версию продукта, и он был задеплоен в продакшен.
Если люди недовольны, они пишут в книгу жалоб - книга жалоб - это сотрудник техподдержки, заодно он - справочное бюро. Сотрудник техподдержки передаёт информацию в нужный отдел - например, если люди жалуются на вкус блинчиков - повару. Если люди жалуются на перебои в поставке блинчиков - то Ops-ам. Если в кафе мигает свет - то электрику.
А DevOps - это такой процесс, когда повару (или отделу Ops) не нужно разносить блюда вручную - это когда у повара есть конвеер, на который он клаёт готовый блинчик, и блинчик автоматически уезжает дальше. Блинчик может уехать сначала к тестировщику, тот его подхватит, проверит, и если всё хорошо - кладёт на другой конвеер, и конвеер отвезёт блинчик пользователям без всяких официантов.
DevOps-инженер отвечает за этот конвеер - настраивает его оптимальным образом, вносит необходимые улучшения, чинит и так далее.
Есть ещё разнообразные менеджеры. Например, product-менеджер приходит к повару и говорит, что мы сейчас будем двигаться в сторону ЗОЖ, поэтому блинчики должны быть безглютеновыми и с зеленью. Проджект-менеджер считает, сколько муки нужно повару на неделю, и сколько блинов мы успеем выпустить за это время и договаривается о планах с поваром. Если внезапно закончились яйца или повар заболел и работа застопорилась, проджект должен решить эту проблему и наладить процесс.
Задать вопрос автору блога можно здесь: @hum_it_bot
Как гуманитарий - гуманитарию вопрос (по мотивам последнего поста). А можешь провести сравнения между "должностями" в IT и в какой-то более-менее всем понятной сфере (ну, например, из маркетинга/PR. Что-то типа - devops - это как начальник отдела маркетинга). Или в IT -это совсем по-другому?
Что там происходит в маркетинге, я понятия не имею, если честно, так что буду использовать другую метафору - блинчики.
Представим, что IT-компания - это кафешка с блинчиками.
Там есть повар - человек, который печет блинчики. Это программист, он делает продукт для пользователей, а программа, написанная им - это блинчик.
Есть электрик - его задача, чтобы в сети было электричество и плита работала, чтобы повар мог печь блинчики. Это системный администратор.
Есть тестировщик - он пробует готовый блинчик, а потом приносит его обратно повару (разработчику) и говорит: слишком солёный, надо переделать.
Если в компании не налажены процессы ci/cd (continuous integration, continuous delivery) - то есть непрерывный процесс доставки готового продукта конечному пользователю - кто-то должен приносить клиентам блинчики, то есть играть роль официанта. Например, это может делать сам повар - тогда ему придется тратить свое время еще и на обслуживание столов. Или это будут делать особые админы (Ops) - они тут как официанты, должны получать блинчики от ̶р̶а̶з̶р̶а̶б̶о̶т̶ч̶и̶к̶а̶, разносить их людям, следить, чтобы все столы обслуживались вовремя и качественно.
Сам процесс доставки блинчика потребителю называется деплоймент. Например, когда какой-нибудь сайт Вконтакте обновляет свою версию, и там появляются новые кнопки - значит разработчики выпустили новую версию продукта, и он был задеплоен в продакшен.
Если люди недовольны, они пишут в книгу жалоб - книга жалоб - это сотрудник техподдержки, заодно он - справочное бюро. Сотрудник техподдержки передаёт информацию в нужный отдел - например, если люди жалуются на вкус блинчиков - повару. Если люди жалуются на перебои в поставке блинчиков - то Ops-ам. Если в кафе мигает свет - то электрику.
А DevOps - это такой процесс, когда повару (или отделу Ops) не нужно разносить блюда вручную - это когда у повара есть конвеер, на который он клаёт готовый блинчик, и блинчик автоматически уезжает дальше. Блинчик может уехать сначала к тестировщику, тот его подхватит, проверит, и если всё хорошо - кладёт на другой конвеер, и конвеер отвезёт блинчик пользователям без всяких официантов.
DevOps-инженер отвечает за этот конвеер - настраивает его оптимальным образом, вносит необходимые улучшения, чинит и так далее.
Есть ещё разнообразные менеджеры. Например, product-менеджер приходит к повару и говорит, что мы сейчас будем двигаться в сторону ЗОЖ, поэтому блинчики должны быть безглютеновыми и с зеленью. Проджект-менеджер считает, сколько муки нужно повару на неделю, и сколько блинов мы успеем выпустить за это время и договаривается о планах с поваром. Если внезапно закончились яйца или повар заболел и работа застопорилась, проджект должен решить эту проблему и наладить процесс.
Задать вопрос автору блога можно здесь: @hum_it_bot
#вашивопросы
Потихоньку программирую на питоне для души. Возник вопрос - что почитать про культуру программирования?
Речь не только о стиле написания кода, но и о сопутствующих вещах - например как хранить входные и выходные txt файлы и сами программы (все "плоско" или по папкам)?
Если две программы незначительно отличаются (в т.ч. например входными и выходными файлами, и другими параметрами), делать эти программы в виде отдельных файлов? Или в одном, просто закомментировав соответствующим образом те строки, которые могут работать по варианту А или по варианту B?
Насколько я понимаю, у вас сейчас есть набор небольших скриптов, которые делают что-то плюс-минус похожее - например, обрабатывают текстовые файлы.
Предлагаю пересмотреть их код так, чтобы он больше напоминал полноценную программу (или даже библиотеку).
В разработке есть такой принцип как DRY - don’t repeat yourself. Одну задачу в коде нужно решать ровно один раз, а не повторять один и тот же код много раз в разных местах - и, вероятно, этот принцип в ваших скриптах нарушается.
Выделяете ли вы фрагменты логики программ в отдельные функции, или код состоит из «плоского» набора инструкций? Если второй вариант - то сперва подумайте, что в коде можно вынести в отдельные функции.
Наверняка ваши скрипты делают что-то одинаковое. Например, одинаковым образом парсят текстовые файлы. Значит, можно написать функцию parse_file(filename) и вынести её в отдельный модуль, например, parse.py, а в самих скриптах импортировать её командой from parse import parse_file и использовать в коде. В этот же модуль можно поместить еще какие-то функции, отвечающие за обработку текста.
В другой модуль - вынести, например, код, отвечающий за загрузку данных из Интернета.
Если таких модулей получилось немного, можно их хранить в одной и той же папке. Если же их много - удобно и логично их сгруппировать по разным папкам с информативными именами.
Комментировать никакие строки не нужно. Я полагаю, что ваши скрипты настолько похожи, что их можно переделать в 1 скрипт, который будет принимать разные данные в качестве аргументов и в зависимости переданных параметров, выполнять свою работу чуть-чуть по-разному.
Например:
Чтобы он сделать что-то с файлом
Что касается того, где хранить файлы с данным (например, .txt) - вероятно, файлы с данными не относятся к самой программе, и хранить их вместе с кодом нет смысла, храните их там, где вам удобно.
Но есть случаи, когда текстовой файл является частью программы - тогда его можно хранить вместе с модулем, либо в соседней папке. Пример: мы при обработке текста используем список стоп-слов, который хранится в текстовом файле. Когда программа встречает в данных стоп-слово - она просто пропускает это слово без всякой обработки. Вот словарь со списком стоп-слов - это данные, которые являются частью программы.
Не знаю, существуют ли какие-то сформулированные общие стандарты по тому, как разбивать код на модули и папочки - не припомню, чтобы я где-то такое читала в полном виде. Основной принцип - чтобы всё хранилось удобно, логично и понятно. Вы можете посмотреть исходный код известных (и неизвестных тоже) проектов на github - вот, например, ссылка на репозиторий flask - https://github.com/pallets/flask или джанго - https://github.com/django/django - полазайте по проектам - посмотрите, какой логикой руководствовались авторы кода, разбивая его на модули и папки. И перенимайте их опыт.
Задать вопрос автору блога можно здесь: @hum_it_bot
Потихоньку программирую на питоне для души. Возник вопрос - что почитать про культуру программирования?
Речь не только о стиле написания кода, но и о сопутствующих вещах - например как хранить входные и выходные txt файлы и сами программы (все "плоско" или по папкам)?
Если две программы незначительно отличаются (в т.ч. например входными и выходными файлами, и другими параметрами), делать эти программы в виде отдельных файлов? Или в одном, просто закомментировав соответствующим образом те строки, которые могут работать по варианту А или по варианту B?
Насколько я понимаю, у вас сейчас есть набор небольших скриптов, которые делают что-то плюс-минус похожее - например, обрабатывают текстовые файлы.
Предлагаю пересмотреть их код так, чтобы он больше напоминал полноценную программу (или даже библиотеку).
В разработке есть такой принцип как DRY - don’t repeat yourself. Одну задачу в коде нужно решать ровно один раз, а не повторять один и тот же код много раз в разных местах - и, вероятно, этот принцип в ваших скриптах нарушается.
Выделяете ли вы фрагменты логики программ в отдельные функции, или код состоит из «плоского» набора инструкций? Если второй вариант - то сперва подумайте, что в коде можно вынести в отдельные функции.
Наверняка ваши скрипты делают что-то одинаковое. Например, одинаковым образом парсят текстовые файлы. Значит, можно написать функцию parse_file(filename) и вынести её в отдельный модуль, например, parse.py, а в самих скриптах импортировать её командой from parse import parse_file и использовать в коде. В этот же модуль можно поместить еще какие-то функции, отвечающие за обработку текста.
В другой модуль - вынести, например, код, отвечающий за загрузку данных из Интернета.
Если таких модулей получилось немного, можно их хранить в одной и той же папке. Если же их много - удобно и логично их сгруппировать по разным папкам с информативными именами.
Комментировать никакие строки не нужно. Я полагаю, что ваши скрипты настолько похожи, что их можно переделать в 1 скрипт, который будет принимать разные данные в качестве аргументов и в зависимости переданных параметров, выполнять свою работу чуть-чуть по-разному.
Например:
python parse_log_files.py ~/Downloads/log1.txtЧтобы он сделать что-то с файлом
~/Downloads/log1.txt. Если понадобится обработать другой файл - подставьте путь к нему в аргументе при запуске скрипта. Также можно использовать и подставлять любые дополнительные параметры, которые вы определите. Почитайте про модуль argparse, и будет вам счастье: https://docs.python.org/3/library/argparse.htmlЧто касается того, где хранить файлы с данным (например, .txt) - вероятно, файлы с данными не относятся к самой программе, и хранить их вместе с кодом нет смысла, храните их там, где вам удобно.
Но есть случаи, когда текстовой файл является частью программы - тогда его можно хранить вместе с модулем, либо в соседней папке. Пример: мы при обработке текста используем список стоп-слов, который хранится в текстовом файле. Когда программа встречает в данных стоп-слово - она просто пропускает это слово без всякой обработки. Вот словарь со списком стоп-слов - это данные, которые являются частью программы.
Не знаю, существуют ли какие-то сформулированные общие стандарты по тому, как разбивать код на модули и папочки - не припомню, чтобы я где-то такое читала в полном виде. Основной принцип - чтобы всё хранилось удобно, логично и понятно. Вы можете посмотреть исходный код известных (и неизвестных тоже) проектов на github - вот, например, ссылка на репозиторий flask - https://github.com/pallets/flask или джанго - https://github.com/django/django - полазайте по проектам - посмотрите, какой логикой руководствовались авторы кода, разбивая его на модули и папки. И перенимайте их опыт.
Задать вопрос автору блога можно здесь: @hum_it_bot
Python documentation
argparse — Parser for command-line options, arguments and subcommands
Source code: Lib/argparse.py Tutorial: This page contains the API reference information. For a more gentle introduction to Python command-line parsing, have a look at the argparse tutorial. The arg...
Коронавирус повлиял на все сферы жизни, но по-разному. Ресторанному бизнесу сейчас очень плохо, а IT-сектор наоборот — только ускорился в развитии. Акции компаний выросли, сами компании постепенно расширяются и ищут новых специалистов. На всякий случай: вы же знаете, что это не только программисты?
Например, проджект-менеджеры в IT не менее востребованы. И если вы хотите поменять свою профессию на более актуальную, то вам в SkillFactory. Они запустили полноценный годовой курс по управление digital-проектами, где на практике обучают софт- и хард- скиллам.
Персональный тьютор, общение с менторами из Яндекса, Тинькофф-банка и МТС, карьерные консультации — все, чтобы вы нашли работу после курса как можно скорее.
🎄Если вы не знали, что подарить себе на Новый год, то новая профессия —
отличный вариант.
По промокоду ГУМАНИТАРИЙ скидка будет 55%
❗️Успейте получить курс со скидкой: https://clc.am/alSR4Q
Например, проджект-менеджеры в IT не менее востребованы. И если вы хотите поменять свою профессию на более актуальную, то вам в SkillFactory. Они запустили полноценный годовой курс по управление digital-проектами, где на практике обучают софт- и хард- скиллам.
Персональный тьютор, общение с менторами из Яндекса, Тинькофф-банка и МТС, карьерные консультации — все, чтобы вы нашли работу после курса как можно скорее.
🎄Если вы не знали, что подарить себе на Новый год, то новая профессия —
отличный вариант.
По промокоду ГУМАНИТАРИЙ скидка будет 55%
❗️Успейте получить курс со скидкой: https://clc.am/alSR4Q
#вашивопросы
Имеется цель-сменить профессию, войти в Айти, решил начать с фронтенда, т.к. наткнулся на инфу, что с фронтенда проще начать, но уже не раз слышал мнения программистов с опытом, что то типа если рэп это музыка, то фронтенд это программирование. Как считаете, можно ли начать с фронтенда, потом изучить бэкенд, или времени не будет хватать? И правда ли что фронтенд это не совсем программирование?
Это вы столкнулись с профессиональным снобизмом: некоторые специалисты считают себя круче других, и смотрят на них свысока. Например, есть разработчики, которые свысока смотрят на тестировщиков, разработчики на C++ могут смотреть свысока на питонистов, бэкендеры на фронтэндеров, и еще сотни разных вариаций.
В каких-то случаях у людей даже есть свои основания для чувства собственного превосходства - кто-то пишет сложнейшие программы на С++, а кто-то - простейшие веб-сервисы на Go или Python. Кто-то разрабатывает очень крутые алгоритмы с продвинутой математикой, а кто-то верстает html.
Но мой вам совет - не участвуйте в этом детском саду. Занимайтесь тем, что вам интересно, и тем, чем считаете нужным. Ну не так «крут» фротэнд, как разрабатывать операционные системы, или создавать криптографические алгоритмы. Но это не значит, что он менее нужен или менее полезен.
Под этим постом будет картинка-схема про то, какие программисты считают себя лучше других (шуточная, конечно).
Что же касается вопроса о том, с чего начать - вы выбираете фронтэнд, потому что кто-то сказал, что с него легче начинать. Моё (субъективное!) мнение в том, что начинать лучше с того, что сложнее. Не настаиваю на том, что это универсальный подход, и что все должны делать только так - возможно, кому-то и правда проще начать с более легкого, чтобы не потерять мотивацию. Решайте сами. Но я бы начала с бэкенда. Или же сразу изучайте фулстэк-разработку, раз задумались и о фронте, и о бэке.
Задать вопрос автору блога можно здесь: @hum_it_bot
Имеется цель-сменить профессию, войти в Айти, решил начать с фронтенда, т.к. наткнулся на инфу, что с фронтенда проще начать, но уже не раз слышал мнения программистов с опытом, что то типа если рэп это музыка, то фронтенд это программирование. Как считаете, можно ли начать с фронтенда, потом изучить бэкенд, или времени не будет хватать? И правда ли что фронтенд это не совсем программирование?
Это вы столкнулись с профессиональным снобизмом: некоторые специалисты считают себя круче других, и смотрят на них свысока. Например, есть разработчики, которые свысока смотрят на тестировщиков, разработчики на C++ могут смотреть свысока на питонистов, бэкендеры на фронтэндеров, и еще сотни разных вариаций.
В каких-то случаях у людей даже есть свои основания для чувства собственного превосходства - кто-то пишет сложнейшие программы на С++, а кто-то - простейшие веб-сервисы на Go или Python. Кто-то разрабатывает очень крутые алгоритмы с продвинутой математикой, а кто-то верстает html.
Но мой вам совет - не участвуйте в этом детском саду. Занимайтесь тем, что вам интересно, и тем, чем считаете нужным. Ну не так «крут» фротэнд, как разрабатывать операционные системы, или создавать криптографические алгоритмы. Но это не значит, что он менее нужен или менее полезен.
Под этим постом будет картинка-схема про то, какие программисты считают себя лучше других (шуточная, конечно).
Что же касается вопроса о том, с чего начать - вы выбираете фронтэнд, потому что кто-то сказал, что с него легче начинать. Моё (субъективное!) мнение в том, что начинать лучше с того, что сложнее. Не настаиваю на том, что это универсальный подход, и что все должны делать только так - возможно, кому-то и правда проще начать с более легкого, чтобы не потерять мотивацию. Решайте сами. Но я бы начала с бэкенда. Или же сразу изучайте фулстэк-разработку, раз задумались и о фронте, и о бэке.
Задать вопрос автору блога можно здесь: @hum_it_bot
Подписчики прислали ссылку - https://github.com/kamranahmedse/developer-roadmap - пролистайте вниз, там есть роудмапы про то, как развиваться в зависимости от выбранного направления - бэкенд, фронтэнд или DevOps.
Пригодится, чтобы сориентироваться, какие темы изучать и в каком порядке.
Если вас напугает объём материалов, знайте: я сама знакома далеко не со всеми темами, которые есть в схеме про бэкенд. Обычно стэк отдельного специалиста зависит от тех технологий, которые используются конкретно на его работе (и на бывших работах). Например, я никогда не работала с MongoDB и пока с ней где-нибудь не столкнусь, мне и не нужно в ней разбираться.
Так что можно использовать эти схемы как общие ориентиры, но не как железные правила.
Пригодится, чтобы сориентироваться, какие темы изучать и в каком порядке.
Если вас напугает объём материалов, знайте: я сама знакома далеко не со всеми темами, которые есть в схеме про бэкенд. Обычно стэк отдельного специалиста зависит от тех технологий, которые используются конкретно на его работе (и на бывших работах). Например, я никогда не работала с MongoDB и пока с ней где-нибудь не столкнусь, мне и не нужно в ней разбираться.
Так что можно использовать эти схемы как общие ориентиры, но не как железные правила.
GitHub
GitHub - kamranahmedse/developer-roadmap: Interactive roadmaps, guides and other educational content to help developers grow in…
Interactive roadmaps, guides and other educational content to help developers grow in their careers. - kamranahmedse/developer-roadmap
ООП. Абстракция. Инкапсуляция
Продолжаем серию постов о введении в ООП.
В предыдущих сериях:
1. Что такое классы
2. Что такое объекты классов и как их создавать. Конструкторы
3. Что такое ООП
Сегодня на пальцах разберём такие принципы ООП как абстракция и инкапсуляция.
Абстракция
С абстракицей всё достаточно просто. Вспомним класс User из предыдущих постов:
В реальном мире юзер - это человек, очень сложный объект, который не опишешь двумя строчками. А в нашей программе объект User - это всего лишь набор данных: имя, возраст и телефон. Ничего более сложного для нашей программы и не нужно знать. Принцип абстракции в том и заключается, чтобы используемые в программировании объекты содержали только необходимые для программы элементы, а всё остальное можно просто отбросить.
Инкапсуляция
Чтобы разобраться с тем, что такое инкапсуляция, возьмём такой пример как телевизор. Внутри телевизора есть много разных деталей, он устроен сложно. Но простым пользователям вскрывать корпус телевизора и смотреть, что там внутри нельзя (так пишут в инструкции, иначе телевизор не примут на гарантийное обслуживание). Что там внутри пользователь знать и не должен - и это и есть принцип сокрытия информации (он же - инкапсуляция), характерный для ООП.
Специально для пользователя придуман пульт - с кнопками вкл и выкл, регуляторами громкости и возможностью переключать каналы. Только этот набор действий доступен пользователю телевизора. Набор операция, предназначенный для внешнего использования называется публичный интерфейс, и пульт - это внешний интерфейс телевизора.
Принцип инкапсуляции в ООП выглядит обычно так: когда мы определяем класс, в нём тоже есть публичный интерфейс - те методы, которые можно использовать за пределами класса. И есть скрытая часть - те «внутренности», к которым нельзя обращаться извне. В некоторых языках программирования для этой цели придуманы модификаторы доступа - например, public и private - они как раз и показывают, является ли данный метод публичным и открытым для всех, или же это скрытые внутренние детали.
Раз уж у нас такая метафора, определим класс Телевизор c его публичным интерфейсом, и приватными методами:
Приватный метод обычным пользователям недоступен, его могут использовать только «разработчики телевизора» для каких-то встроенных функций.
Зачем придуман метод сокрытия информации? Например, для того, чтобы пользователь не сломал телевизор. Чтобы ему было легко пользоваться телевизором, не зная, как он устроен. Чтобы инженеры могли отремонтировать телевизор внутри - заменить там часть деталей, поменять что-то в его механизме - при этом для пользователя ничего не изменится, так как не изменится публичный интерфейс телевизора. То есть пульт и все кнопки на нём будут работать, как и прежде, несмотря на то, что в телевизоре многое изменилось.
Таким же образом мы можем поменять код внутри нашего класса, класс будет использовать другую логику и другие алгоритмы, но если при этом не изменится публичный интерфейс - все публичные методы будут давать такой же результат, как и раньше - нам не придётся менять код, работающий с этим классом. Это позволяет проще и быстрее менять код и избегать лишних ошибок при внесении изменений.
Продолжаем серию постов о введении в ООП.
В предыдущих сериях:
1. Что такое классы
2. Что такое объекты классов и как их создавать. Конструкторы
3. Что такое ООП
Сегодня на пальцах разберём такие принципы ООП как абстракция и инкапсуляция.
Абстракция
С абстракицей всё достаточно просто. Вспомним класс User из предыдущих постов:
class User {
string name;
int age;
string phone;
function say_hello() {
print(«Hello! My name is {name}»);
}
}В реальном мире юзер - это человек, очень сложный объект, который не опишешь двумя строчками. А в нашей программе объект User - это всего лишь набор данных: имя, возраст и телефон. Ничего более сложного для нашей программы и не нужно знать. Принцип абстракции в том и заключается, чтобы используемые в программировании объекты содержали только необходимые для программы элементы, а всё остальное можно просто отбросить.
Инкапсуляция
Чтобы разобраться с тем, что такое инкапсуляция, возьмём такой пример как телевизор. Внутри телевизора есть много разных деталей, он устроен сложно. Но простым пользователям вскрывать корпус телевизора и смотреть, что там внутри нельзя (так пишут в инструкции, иначе телевизор не примут на гарантийное обслуживание). Что там внутри пользователь знать и не должен - и это и есть принцип сокрытия информации (он же - инкапсуляция), характерный для ООП.
Специально для пользователя придуман пульт - с кнопками вкл и выкл, регуляторами громкости и возможностью переключать каналы. Только этот набор действий доступен пользователю телевизора. Набор операция, предназначенный для внешнего использования называется публичный интерфейс, и пульт - это внешний интерфейс телевизора.
Принцип инкапсуляции в ООП выглядит обычно так: когда мы определяем класс, в нём тоже есть публичный интерфейс - те методы, которые можно использовать за пределами класса. И есть скрытая часть - те «внутренности», к которым нельзя обращаться извне. В некоторых языках программирования для этой цели придуманы модификаторы доступа - например, public и private - они как раз и показывают, является ли данный метод публичным и открытым для всех, или же это скрытые внутренние детали.
Раз уж у нас такая метафора, определим класс Телевизор c его публичным интерфейсом, и приватными методами:
class TVSet {
public turnOn();
public turnOff();
public nextChannel();
private changeSecretParameter();
}Приватный метод обычным пользователям недоступен, его могут использовать только «разработчики телевизора» для каких-то встроенных функций.
Зачем придуман метод сокрытия информации? Например, для того, чтобы пользователь не сломал телевизор. Чтобы ему было легко пользоваться телевизором, не зная, как он устроен. Чтобы инженеры могли отремонтировать телевизор внутри - заменить там часть деталей, поменять что-то в его механизме - при этом для пользователя ничего не изменится, так как не изменится публичный интерфейс телевизора. То есть пульт и все кнопки на нём будут работать, как и прежде, несмотря на то, что в телевизоре многое изменилось.
Таким же образом мы можем поменять код внутри нашего класса, класс будет использовать другую логику и другие алгоритмы, но если при этом не изменится публичный интерфейс - все публичные методы будут давать такой же результат, как и раньше - нам не придётся менять код, работающий с этим классом. Это позволяет проще и быстрее менять код и избегать лишних ошибок при внесении изменений.
В последнее время, когда я читаю вопросы подписчиков, то прихожу к выводу, что люди склонны слишком долго раздумывать, прежде чем что-то попробовать и начать.
Я понимаю, когда речь идёт о покупке дорогого курса - никому не хочется просто потерять большую сумму денег, и тут понятно, что люди хотят быть до конца уверены, что уже готовы с головой уходить в IT, всерьёз и надолго.
Но чего я не понимаю - так это когда человек не может решиться сделать первый шаг, когда речи о каких-то серьезных расходах вообще не идёт. Всё ходит кругами, присматривается, прикидывается - а точно стоит пробовать, а что именно пробовать, а может не стоит, или всё же попробовать, или нет? А как не ошибиться в выборе курса/платформы/предмета?
Так вот, ребят. Перестаньте уже. Просто начните с чего-нибудь.
Нечего раздумывать перед тем, как записаться, например, на бесплатный вебинар по программированию. Он же бесплатный! Не понравится - можно не дослушивать до конца, к чему вообще эти сомнения? То же касается бесплатных курсов - нет смысла выбирать их с каким-то особым пристрастием и долго раздумывать. Помимо cs50 есть еще другие варианты на edx или на stepik (для тех, кому важно, чтобы на русском языке было), и еще много где.
Кроме бесплатных курсов есть целый океан недорогих курсов. Если у вас есть 1000 рублей, и это не ваши последние деньги, можно смело идти на какой-нибудь Udemy (UPD 2022 - cейчас из-за санкций оплатить курсы студентам из России там нельзя) и выбирать любой курс, связанный с IT - они там обычно небольшие - многие можно пройти за пару недель, максимум за месяц. Посмотрите в требованих, что курс подходит для изучения с нуля и вперёд. И не так уж важно на этом этапе определяться с направлением - можно пробовать всё подряд - курс по веб-разработке, или общее введение в программирование, или курс по созданию игр. Поэкспериментируйте, напишите свои первые небольшие програмки, поиграйтесь с кодом - и смотрите по своим ощущениям - нравится это или нет, и хотите ли вы дальне разиваться в этом направлении.
Помимо всего этого есть книги - если время позволяет - покупаете книгу (можно перед этим отзывы почитать), открываете и читаете.
А дальше уже можно будет решаться на что-то более серьезное - например, записываться на полуторагодовую учебную программу уже за серьезные деньги, или искать курсы при IT-компаниях.
А то так можно всю жизнь провести в сомнениях.
Я понимаю, когда речь идёт о покупке дорогого курса - никому не хочется просто потерять большую сумму денег, и тут понятно, что люди хотят быть до конца уверены, что уже готовы с головой уходить в IT, всерьёз и надолго.
Но чего я не понимаю - так это когда человек не может решиться сделать первый шаг, когда речи о каких-то серьезных расходах вообще не идёт. Всё ходит кругами, присматривается, прикидывается - а точно стоит пробовать, а что именно пробовать, а может не стоит, или всё же попробовать, или нет? А как не ошибиться в выборе курса/платформы/предмета?
Так вот, ребят. Перестаньте уже. Просто начните с чего-нибудь.
Нечего раздумывать перед тем, как записаться, например, на бесплатный вебинар по программированию. Он же бесплатный! Не понравится - можно не дослушивать до конца, к чему вообще эти сомнения? То же касается бесплатных курсов - нет смысла выбирать их с каким-то особым пристрастием и долго раздумывать. Помимо cs50 есть еще другие варианты на edx или на stepik (для тех, кому важно, чтобы на русском языке было), и еще много где.
Кроме бесплатных курсов есть целый океан недорогих курсов. Если у вас есть 1000 рублей, и это не ваши последние деньги, можно смело идти на какой-нибудь Udemy (UPD 2022 - cейчас из-за санкций оплатить курсы студентам из России там нельзя) и выбирать любой курс, связанный с IT - они там обычно небольшие - многие можно пройти за пару недель, максимум за месяц. Посмотрите в требованих, что курс подходит для изучения с нуля и вперёд. И не так уж важно на этом этапе определяться с направлением - можно пробовать всё подряд - курс по веб-разработке, или общее введение в программирование, или курс по созданию игр. Поэкспериментируйте, напишите свои первые небольшие програмки, поиграйтесь с кодом - и смотрите по своим ощущениям - нравится это или нет, и хотите ли вы дальне разиваться в этом направлении.
Помимо всего этого есть книги - если время позволяет - покупаете книгу (можно перед этим отзывы почитать), открываете и читаете.
А дальше уже можно будет решаться на что-то более серьезное - например, записываться на полуторагодовую учебную программу уже за серьезные деньги, или искать курсы при IT-компаниях.
А то так можно всю жизнь провести в сомнениях.
Комментарий по поводу вашего последнего поста о сомнениях.
Я купила курс на geekbrains и javarush. Просто так сложилось, что появились средства.
Но я из тех людей, кому жалко 1000 р на udemy, потому что у меня нет точной гарантии, что этот курс мне что-то даст. Мне его никто (из тех кому я могу доверять) не посоветовал, а рандомным отзывам, зачастую проплаченным, я отношусь со скепсисом.
Легко рассуждать с зарплатой в 250 тыс о 1000 р за курс, а у кого-то зарплаты копеечные, или их временно вообще не выплачивают.
С 2017 года примерно натыкаюсь на разные курсы бесплатные, или марафоны на темы смм, копирайта, геймдизайна и т.д. Полезного материала в них кот наплакал, и очень много рекламы собственных курсов уже платных. И жалко потраченного времени.
Не все бесплатные курсы так себе. Мне понравились курсы от мисис на openedu. Самый минимум и вводную инфу по Java и html/css я получила в бесплатном sololearn.
Возможно, огромное количество инфоцыган дискредитировали эту отрасль с бесплатными/вводными курсами, что люди уже не хотят такое пробоватьСпасибо за комментарий!
По поводу 1000 рублей - я специально оговорилась, что если эта сумма для вас некритична, и вы можете потратить ее раз в месяц безболезненно для своего бюджета, тогда тут раздумывать особо не о чем. Если же это выходит за рамки бюджета - тогда другое дело.
Что касается опасений по поводу инфоцыганства в бесплатных курсах - мое (субъективное!) мнение - всё зависит от тематики курса. И в условно гуманитарных направлениях (копирайт и вот это всё) - в среднем гораздо больше воды, её туда легко налить.
А технические дисциплины - это работа с конкретными технологиями, включающая в себя много практики. Ну то есть, если я встречаю курс по темам «Ассемблеры» или «SQL и Базы данных», «Разрабатываем игру на Unity» или «Основы математической статистики для Data Science» - я вот с трудом представляю, как туда вообще можно впихнуть какое-то инфоцыганство. Это считай как лекции + лабораторные работы на усвоение материала.
Попробуйте рассказать про ядро Linux в инфоцыганском ключе, интересно было бы такое послушать.
Но ощущение, что инфоцыгане в принципе испортили репутацию образовательных продуктов как таковых.
Лично я училась на таких платфомрах как Coursera, Edx, Stepik, MIT online, Stanford online - и прочих агрегаторах курсов, и мне даже в голову не приходило, где-то там искать подвох (и я его не встречала). Всё это было к тому же бесплатно.
И сейчас, когда у меня возникает потребность или желание познакомиться с какой-то новой для меня темой - я обычно делаю то же самое - беру какой-то короткий курс на coursera/udemy/udacity итд итп - и изучаю его. И, думаю, очень многие айтишники время от времени так делают.
Не факт, что любой случайный курс в Интернете окажется хорошим - гарантии, разумеется, нет. Но всё же программирование - это обучение навыку, сделать курс из одной болтовни - это нужно прям сильно постараться.
Мне кажется, многие сомневаются не из-за денег, а из-за времени/энергии, хватит ли сил после рабочего дня заниматься на курсах, осваивать новую информацию, делать домашние задания и т.д. И сколько времени хватит существовать в таком режиме, если в дополнение имеющейся пятидневке (со своими авралами и кранчами) вечера, выходные и отпуска будут заняты учебой, а также как к такому отнесутся жена/муж/дети (даже если они в целом поддерживают идею сменить род деятельности).Понимаю, резко менять направление в жизни - это страшно и потребует дополнительного времени и ресурсов.
Но в описанной вами ситуации речь идёт как раз о сценарии, когда человек «с головой» уходит в учёбу - занимается каждый вечер, регулярно выкраивает время на учебу - при этом надо еще успевать работать, и уделять время семье. Безусловно, на такое еще нужно решиться.
Я же говорю о случае, когда вы еще не приняли окончательное решение, и вопрос пока стоит о том, чтобы пройти ради эксперимента или из любопытства небольшой курс - тот, что займет пару недель и ни к чему обязывать не будет. Или же почитать книгу.
На этом этапе не потребуется каких-то сверхусилий и особого тайм-менеджмента. Зато появится хотя бы поверхностное представление о том, что такое IT, и станет легче определиться - интересно ли это вам вообще.
Я, например, первый курс по программированию прошла из любопытства и совершенно случайно. И первое время у меня и не было каких-то серьезных планов. Лишь через полгода я уже приняла осмысленное решение - заниматься IT всерьез и основательно углублять свои знания.
Сделать первый шаг - не значит прилагать сверхусилия.
Куда пропали 8 лет?
Вот вы спрашиваете, нужно ли указывать в резюме опыт работы, не связанный с IT.
Вместо ответа расскажу историю. Обсуждали как-то с коллегами резюме кандидатки. Главный вопрос, который стоял на повестке: в резюме была «дыра» длиной в 8 лет - непонятно, чем занималась эти 8 лет и почему об этом не написала. И все стали предлагать свои версии.
Моя гипотеза была самой простой - девушка ушла в декрет и потом решила не возвращаться на работу, и так затянулось на 8 лет. А может, было несколько декретов.
Другой коллега очень настаивал на более романтической версии, что девушка - агент спецслужб, какой-нибудь ФСБ или ГРУ там она и провела 8 лет, и ей просто нельзя писать в резюме, ГДЕ она работала, «но мы-то всё понимаем» - хитрая ухмылка.
В итоге оказалось, что кандидатка 8 лет работала бухгалтером, но решила об этом не писать в резюме, так как к вакансии, на которую она претендовала, этот опыт не имел отношения.
Так что ответ однозначный - пишите о том, чем раньше занимались. Не надо расписывать целые абзацы, их читать никто не будет. Но хотя бы 1 строкой напишите. А то люди подумают, что вы агент спецслужб. 🙂
Вот вы спрашиваете, нужно ли указывать в резюме опыт работы, не связанный с IT.
Вместо ответа расскажу историю. Обсуждали как-то с коллегами резюме кандидатки. Главный вопрос, который стоял на повестке: в резюме была «дыра» длиной в 8 лет - непонятно, чем занималась эти 8 лет и почему об этом не написала. И все стали предлагать свои версии.
Моя гипотеза была самой простой - девушка ушла в декрет и потом решила не возвращаться на работу, и так затянулось на 8 лет. А может, было несколько декретов.
Другой коллега очень настаивал на более романтической версии, что девушка - агент спецслужб, какой-нибудь ФСБ или ГРУ там она и провела 8 лет, и ей просто нельзя писать в резюме, ГДЕ она работала, «но мы-то всё понимаем» - хитрая ухмылка.
В итоге оказалось, что кандидатка 8 лет работала бухгалтером, но решила об этом не писать в резюме, так как к вакансии, на которую она претендовала, этот опыт не имел отношения.
Так что ответ однозначный - пишите о том, чем раньше занимались. Не надо расписывать целые абзацы, их читать никто не будет. Но хотя бы 1 строкой напишите. А то люди подумают, что вы агент спецслужб. 🙂
С Новым годом, товарищи!
Пока вкатываться в рабочий режим еще рано, выложу пару древних, но очень смешных видео на тему IT:
The Website is Down - про будни веселого админа: https://www.youtube.com/watch?v=uRGljemfwUE
Wat - про странности языков программирования: https://www.destroyallsoftware.com/talks/wat
Всё на инглише (sorry)
Пока вкатываться в рабочий режим еще рано, выложу пару древних, но очень смешных видео на тему IT:
The Website is Down - про будни веселого админа: https://www.youtube.com/watch?v=uRGljemfwUE
Wat - про странности языков программирования: https://www.destroyallsoftware.com/talks/wat
Всё на инглише (sorry)
YouTube
The Website is Down #1: Sales Guy vs. Web Dude
The Website is Down: Sales Guy Vs. Web Dude High Quality
The original video in high resolution.
This video won a Webby award!
The original video in high resolution.
This video won a Webby award!