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

Хочу войти в 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

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

Можете посоветовать необходимую базу (книги, курсы, технологии и пр.) чтобы при входе в сферу не только владеть определенными навыками (которые я изучу в онлайн университете, например), но и понимать больше и быть более профессиональным специалистом? Например тот, кто уже в вузе или школе стал интересоваться программированием и изучил разные направления явно сильнее чем тот, кто просто прошел курсы по определенному узкому стеку.
Например, пройти 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

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

Как гуманитарий - гуманитарию вопрос (по мотивам последнего поста). А можешь провести сравнения между "должностями" в 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 скрипт, который будет принимать разные данные в качестве аргументов и в зависимости переданных параметров, выполнять свою работу чуть-чуть по-разному.

Например:

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

Коронавирус повлиял на все сферы жизни, но по-разному. Ресторанному бизнесу сейчас очень плохо, а IT-сектор наоборот — только ускорился в развитии. Акции компаний выросли, сами компании постепенно расширяются и ищут новых специалистов. На всякий случай: вы же знаете, что это не только программисты?

Например, проджект-менеджеры в IT не менее востребованы. И если вы хотите поменять свою профессию на более актуальную, то вам в SkillFactory. Они запустили полноценный годовой курс по управление digital-проектами, где на практике обучают софт- и хард- скиллам.

Персональный тьютор, общение с менторами из Яндекса, Тинькофф-банка и МТС, карьерные консультации — все, чтобы вы нашли работу после курса как можно скорее.

🎄Если вы не знали, что подарить себе на Новый год, то новая профессия —
отличный вариант.

По промокоду ГУМАНИТАРИЙ скидка будет 55%
❗️Успейте получить курс со скидкой: https://clc.am/alSR4Q

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

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

Это вы столкнулись с профессиональным снобизмом: некоторые специалисты считают себя круче других, и смотрят на них свысока. Например, есть разработчики, которые свысока смотрят на тестировщиков, разработчики на C++ могут смотреть свысока на питонистов, бэкендеры на фронтэндеров, и еще сотни разных вариаций.

В каких-то случаях у людей даже есть свои основания для чувства собственного превосходства - кто-то пишет сложнейшие программы на С++, а кто-то - простейшие веб-сервисы на Go или Python. Кто-то разрабатывает очень крутые алгоритмы с продвинутой математикой, а кто-то верстает html.

Но мой вам совет - не участвуйте в этом детском саду. Занимайтесь тем, что вам интересно, и тем, чем считаете нужным. Ну не так «крут» фротэнд, как разрабатывать операционные системы, или создавать криптографические алгоритмы. Но это не значит, что он менее нужен или менее полезен.

Под этим постом будет картинка-схема про то, какие программисты считают себя лучше других (шуточная, конечно).

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

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

Подписчики прислали ссылку - https://github.com/kamranahmedse/developer-roadmap - пролистайте вниз, там есть роудмапы про то, как развиваться в зависимости от выбранного направления - бэкенд, фронтэнд или DevOps.

Пригодится, чтобы сориентироваться, какие темы изучать и в каком порядке.

Если вас напугает объём материалов, знайте: я сама знакома далеко не со всеми темами, которые есть в схеме про бэкенд. Обычно стэк отдельного специалиста зависит от тех технологий, которые используются конкретно на его работе (и на бывших работах). Например, я никогда не работала с MongoDB и пока с ней где-нибудь не столкнусь, мне и не нужно в ней разбираться.

Так что можно использовать эти схемы как общие ориентиры, но не как железные правила.

ООП. Абстракция. Инкапсуляция

Продолжаем серию постов о введении в ООП.
В предыдущих сериях:
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-компаниях.

А то так можно всю жизнь провести в сомнениях.

Комментарий по поводу вашего последнего поста о сомнениях.
Я купила курс на 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:

The Website is Down - про будни веселого админа: https://www.youtube.com/watch?v=uRGljemfwUE

Wat - про странности языков программирования: https://www.destroyallsoftware.com/talks/wat

Всё на инглише (sorry)

Не буду даже пытаться

Продолжим тему о багах мышления.

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

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

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

А некоторые даже не пытались. Они с порога уходили в отрицание - «я не знаю, я не понимаю, это ты всё знаешь - ты можешь решить, а я не могу».

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

Поэтому и запрос у таких новичков в духе «А дай списать». «Ну ты же всё знаешь, ну что тебе стоит.»

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

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

А некоторые джуны в похожих ситуациях склонны пасовать и отнекиваться, мол «я такого не пробовал, не знаю, не умею» (это мы не проходили, это нам не задавали). Вот только правда в том, что мы, айтишники, очень часто делаем такое, чего не пробовали раньше. Это наша работа.

Так что пытайтесь. Это ключ к успеху. Честно-честно

Ещё про собеседования

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

Перед своими первыми собеседованиями в качестве работодателя, ты носишься по офису, волнуешься, и всех спрашиваешь: «Блин, сейчас придёт кандидат. О чём его спрашивать?». Переживаешь, что вопросы будут глупыми, что кандидат решит, что мы тут все тупые (кандидат ведь вполне может оказаться умнее нас).

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

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

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

1. Можно ли научиться делать именно десктопные версии приложений без углубления в программирование?
2. Какие языки необходимы, чтобы делать приложения канбан досок и интеллект карт? Я понимаю, что это похоже на изобретение велосипеда, но мне хочется попробовать самой сделать подобные приложения. Отсюда вытекает следующий вопрос:
3. А можно вообще научиться программировать не для общих целей, а например как в моем случае из потребности сделать конкретное приложение?

1. Программирование десктопных приложений - это тоже программирование, так что вопрос можно переформулировать как «можно ли научиться программированию, не углубляясь в программирование». Если ваша цель - только написать 2-3 десктопных программы, которым не нужен Интернет, значит на этом этапе можно проигнорировать, скажем, такие темы, как работа с сетью, HTTP-протокол и всё прочее, что не нужно для ваших потребностей. Но вам понадобятся основы программирования на выбранном языке и умение работать с GUI (графический интерфейс пользователя - то есть визуальная часть приложения - окошечки, кнопочки итд).

2. Какие языки выбрать для десктопных программ - во-первых, можно взять любой язык общего пользования, скажем, Python или Java. К ним понадобятся библиотеки для работы с GUI - например, в Python это tkinter или более новые аналоги. Если приложения хотите создавать под Microsoft, можно использовать платформу .Net (скажем, на языке C#). Еще можно использовать Delphi, но как по мне - это устаревший язык.

Ещё один чуть менее очевидный путь - написать веб-приложение на JavaScript и открывать его в браузере - вместо того, чтобы использовать библиотеки для создания GUI. Можно написать его так, чтобы ему не был нужен доступ в Интернет.

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

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

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

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

Как считаете, какие перспективы есть у Flutter и языка программирования Dart? Стоит ли это изучать в 2021?

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

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

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

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

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

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

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

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

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

ООП. Наследование

Праздники закончились, так что продолжим ликбез на тему ООП.

В предыдущих сериях:
1. Что такое классы
2. Что такое объекты классов и как их создавать. Конструкторы
3. Что такое ООП
4. Принципы ООП: абстракция. Инкапсуляция

Сегодня поговорим о таком столпе объектно-ориентированного программирования как наследование.

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

Возьмём пример - пользователь какого-нибудь чата, создадим для него класс BaseUser, чтобы подчеркнуть, что от этого класса будут наследоваться другие "дочерние" классы:

class BaseUser {

string login;
string email;

function send_message() {
// код
}
}

Базовый юзер - это обычный юзер, самый обобщенный вариант. У любого пользователя есть логин, email и любой пользователь может отправлять сообщения.

И тут мы хотим создать не обычного пользователя, а «расширенного» - администратора. Во-первых, у него есть такие же аттрибуты и возможности, как и у базового пользователя - логин, email и он тоже может присылать сообщения. И если воспользоваться механизмом наследования, сделать AdminUser наследником BaseUser, то все эти возможности юзер-админ получает автоматически:

class AdminUser(BaseUser) {
}

Тут мы в скобках указали, что BaseUser - это родитель AdminUser, и таким образом всё, что написано в классе BaseUser будет работать и для AdminUser.

А то, что есть у AdminUser, но не у обычных пользователей, мы определим только в этом классе:

class AdminUser(BaseUser) {

function ban_user(user) {
// код - забанить какого-нибудь пользователя
}
}

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

А еще можно переопределить метод, который админ унаследовал у родительского класса, чтобы он работал по-другому, например:

class AdminUser(BaseUser) {

function send_message() {
// код - печатать сообщения красным цветом
}
}

Метод send_message для админов будет печатать весь текст красным цветом. А поля и методы, которые мы решили не переопределять остались такими же, как в родительском классе.

Наследование может быть многоступенчатым - например, у AdminUser тоже могут быть классы-наследники, а у них в свою очередь - свои наследники. Но такое многоуровневое наследование может необоснованно усложнять код и приводить к ошибкам.

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

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

В следующий раз расскажу про абстрактные классы.

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

Очень-очень хочу узнать Ваше мнение о смене работы.

Я Google Ads специалист уровня Middle+/Senior (так сказать Full stack, с большими проектами за плечами). Если сейчас устроюсь на работу то думаю могу ожидать около 2000$ (если получится 2500$) зп.
НО я уже изучаю Python (давно), куча курсов, пишу свои проекты, в общем готова идти на собеседования на Júnior Python dev.

Скажите, в 10-ти летней перспективе будет ли эта смена профессии правильной? Стоит ли?
Может ли девушка реально быть Senior бэкендщиком с зп выше 3,5-4К$?

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

Ну что начинать работать программистом будет «больно» - это не факт, возможно, будет как раз интересно. А вот что точно можно сказать - это что по первой поре в должности Junior зарплата будет гораздо меньше, чем вы привыкли получать.

Что касается зарплаты больше 3,5к долларов - то есть от 250к рублей и больше - такие вакансии есть, но это зарплата больше среднерыночной, если брать по Москве (скажем, в США разработчики получают больше, чем у нас).

Вакансии на 250к и больше - это часто уже уровень Team Lead или айтишников-руководителей, то есть профессии, где нужны будут не только технические навыки и опыт, но и менеджерские скиллы.

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

Но в целом тут всё индивидуально в зависимости от компании. Одни работодатели даже начальнику отдела платят от силы 120к, а другие готовы платить и 300к хорошим разработчикам. Но, как вы, наверно, догадываетесь, найти работу за 300к будет всё же сложнее, чем за 120-200к.

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

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