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

Я студентка выпускного курса технического вуза, инженер-конструктор. Оценки прекрасные, но (как я считаю) из-за такой логики построения высшего образования, какая у нас есть, знаний у меня не густо. Тут ещё надо учесть, что и работаю я сейчас по специальности, где тоже всё сугубо печально, не интересно. Ближе к сути: как-то вечерком наткнулась на курс "Графический дизайн". Вспомнила, что люблю что бы было красиво, с удовольствием оформляю презентации, хотела бы круто шарить в фотошопе. В общем, глаза загорелись) Но столько но...
~Кординальная смена сферы деятельности: инженер ->творчество
~Мысли: ну и нафига я разбиралась в этих эпюрах 5 лет??

Вопрос вот в чём: как считаете, смогу я приурочить своё понимание техники (путь и на девчачьем уровне) к такой профессии как графический дизайн?

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

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

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

Какие вы можете посоветовать книги по нейронным сетям начинающему? Которые расскажут что это такое, как пишутся и прочее о них.

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

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

Если же у вас уже достаточный бэкграунд, чтобы изучать нейросети - тогда многие рекомендают курс Deep Learning на курсере. Также, чтобы найти простые примеры, можно загуглить «neural network from scratch on numpy».

И, наконец, ответ на ваш вопрос, несколько книг с хорошим рейтингом по данной теме:

- Основы глубокого обучения.
- Создаём нейронную сеть.
- Глубокое обучение с точки зрения практики.

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

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

Я в прошлом финансовый аналитик, чуть касалась баз данных, средний уровень SQL и любительский уровень Python в применении к машинному обучению. Сейчас меняю карьерный трек и свою профессию, очень хочу в разработчики. То есть все, что связано с веб дизайном или тестированием мне не интересно. Но возник вопрос: языков много, как можно их сравнить по применению, объему рынка, з.п ожиданиям и перспективности в целом. Может существуют какие-то полезные статьи, где будет приведено их сравнение? На данный момент мне трудно понять, разработкой чего конкретно я хочу заниматься. Прохожу сейчас CS50, C++ белый пояс (Coursera) и Python (Coursera), чтобы была хотя бы база. Но слышала также о Java, PHP..

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

О зарплатах - в этом посте была картинка с примерными цифрами в зависимости от языка программирования.

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

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

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

Если вас больше интересует фронтэнд-разработка (создание «лицевой» стороны сайтов) - тогда путь один - JavaScript.

Также сейчас в моде яызк Go от гугла.

Если вдруг вам чем-то приглянулась платформа Microsoft - тогда путь в .Net разработку, изучайте язык C#.

PHP - не советую. Его используют только в веб-разработке в качестве бэкенд-языка и он вам не понадобится, если вы уже владеете Python и/или Java.

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

Если вам такое направление интересно - то во-первых, углубляйте свои знания Python (ну или изучайте, скажем, Java, если она вас больше заинтересует). Вместе с языком, обычно изучают его основные фреймворки, например, в случае с Python - это в первую очередь фреймворки для веб-разработки: Django, Flask.

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

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

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

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

Есть мнение, что востребованность фронтэнд-разработчиков снижается, т.к. много новичков идут именно в эту область. Поэтому хотелось бы узнать Вашего мнения: у фронта-джуна есть риск в 2021 застрять на этапе поиска работы? Если "рынок" и правда перенасыщен, повлияет ли это на средний уровень зп?

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

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

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

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

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

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

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

#плохойкод

Как писать красивый код

Красивый код (как и хороший код) - это нечто мифическое: все о нём говорят, но никто не видел.
А вот с плохим кодом сталкивались все.

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

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

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

for (int i; ...) {
      
     
    for (int j;…) {

        // какой-то код

        for (int k;…)) {

           // код

            for (int l;…)) {

                // ещё код

                while (true) {
                    ...
                }
            }
        }
    }
}

То же касается и «многослойных» if-конструкций:

if (smth == true ) {

    // код
 
    if (smth_else == true) {

        if (smth_other == true) {

            // код 
        }
        else {

            // код 
        }
    }
    else if (smth) {

        // код 
    }
}
else {

     // код 
}

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

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

Добрый день, у меня возник вопрос по поводу "плохого кода", а именно (цитата) "циклы внутри циклов внутри циклов внутри циклов" (c), подскажите, пожалуйста, как тогда перебрать все элементы двумерного массива, без использования кмк очевидного цикла внутри цикла?

А я и не говорила, что никогда нельзя писать один цикл внутри другого. Бывают ситуации, когда это нужно или даже неизбежно.

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

То же касается бесконечных «ветвей» if-else. Если ваш код похож на лестницу (за счет отступов перед if-ами и for/while) - вероятно, его нужно упрощать.

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

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

7 дней

Эту неделю мне по работе нужно было заниматься фротэндом сайта (я бэкенд-разработчик), поэтому она прошла в режиме «кодить по 12 часов в день на React». Для тех, кто не в теме, React - это веб-фреймворк на JavaScript.

Так вот, могу заявить официально: чтобы разобраться с React-ом, разработчику с опытом нужно примерно 7 дней.

Вот какие стадии я прошла за неделю:

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

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

Конец недели: React - это довольно просто и удобно. В нём уже всё есть, и практически ничего не нужно придумывать и разрабатывать из головы - берешь готовые компоненты и из них складываешь как конструктор. И документацию в интернете очень легко искать - её много, написана понятным языком. Есть куча дополнительных модулей, в которых точно найдётся всё, что нужно для решения задач. Практически не нужно писать кода на чистом JavaScript. Задача закончена, сайт работает как нужно.

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

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

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

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

Расскажите, пожалуйста, как нашли первую работу программистом, сколько собеседований было до неё

1 собеседование было, после него сразу же устроилась работать. Параллельно собеседовалась во вторую компанию, но туда не попала. Подробнее я об этом писала в этом посте.

Узнала о программе для мам с маленькими детьми (а я как раз она) от центра занятости населения совместно с Синергией. Они предлагают переобучение, в тч на it-специальности. Например, фронтенд, тестирование, создание приложений. Отзывы об этой шляпе только от "наших студентов, которые прошли переподготовку", никаких объективных. Зато о самой Синергии отзывы как о шаражке с инфоцыганами. Это дело бесплатное, если тело одобрят, вроде даже стипендию обещают. Сказали, что мое гуманитарное образование - не помеха. Слышали ли вы о них? Для меня это был бы хороший вариант, бесплатно и дистанционно.

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

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

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

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

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

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

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

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

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

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

Что касается курсов по тестированию, вот небольшая подборка:

- Факультет тестирования ПО от Geekbrains с гарантией трудоустройства. Или более корткий курс Тестировщик ПО там же.

- Курс Тестировщик от Нетологии.

- Курс-симулятор Тестировщик программного обеспечения от Skillfactory.

- Если хотите варианты подешевле и готовы учиться в более самостоятельном режиме, посмотрите список курсов например от Udemy (UPD 2022 - cейчас из-за санкций оплатить курсы студентам из России там нельзя) - там много всего есть, в том числе дешевле тысячи рублей. Тут в отличие от предыдущих вариантов никто не обещает содействие в трудоустройстве, но главное ведь - скиллы, а не то, где вы их приобрели, и сколько за это заплатили.


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

#плохойкод

Сегодня продолжаем серию о том, как не надо писать код.

Смешение стилей

Скажем, в Python многие любят использовавть snake case, то есть соединять слова между собой нижним подчеркиванием, в результате получаются вот такие переменные: my_variable, my_other_variable. А где-то принято использовать camel case: myVariable, myOtherVariable. И тут важна последовательность - если в коде проекта уже принят один стиль, не надо туда добавлять переменные, использующие другой стиль, так чтобы my_variable соседствовали с myVariable.

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

Названия для переменных

Худшее, что можно придумать - это называть переменные x, y, z, a, b, c, var1, var2, num1, num2 и так далее.
Имя переменной должно рассказывать о том, что в ней содержится (помните, что код должен быть читаемым и понятным для другого человека, не только для вас одного?).

Придумывайте информативные имена, например: average_salary, person_age, count_clicks - никаких переменных в одну букву.

Исключение: переменные итераторов (for int i; i++) - в таких циклах традиционно используют переменные i, j, k.

Не забывайте и про имена функций - они тоже должны быть «говорящими». Не называйте функции, например, do_everything() или do_calculations() - из такого имени непонятно, что именно функция делает или считает, нужно конкретнее: find_person_by_id() - например, ни у кого не вызовет недопонимания.

Магические цифры

Magic numbers - это когда вы используете в коде просто цифры.
Например: x = y * 100 / 2 + 365 - и читающему код непонятно, почему мы умножаем y именно на 100 и делим именно на 2, что это за 365, и так далее. Как это исправить? Использовать константы вместо чисел, например:

DAYS_IN_A_YEAR = 365
PERCENT_VALID = 100
DIVIDE_RATE = 2

x = y * PERCENT_VALID / DIVIDE_RATE + DAYS_IN_A_YEAR

Пример - вымышленный, и смысла в этом вычислении нет, он чисто для демонстрации того, как избегать магических чисел.
И да, как вы могли заметить, x и y - это плохие названия для переменных. 🙂

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

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

Вот я и свитчнулся в 32 года в Андроид разработчика. Шёл с некоторыми знаниями по яве и несколько большими именно по Андроиду и инфраструктуре, а проект на Kotlin. "Он простой и не отличается почти". Ну да, как же. Работаю чуть больше месяца, а какие-то базовые вещи о котлине узнаю каждый день. В связи с чем в свободное время стараюсь изучать базу по Котлину. Но появляется такой вот момент: работать над своими проектами времени нет вообще. Пока пришёл к тому, что в один из вечеров выходных вместо отдыха время отдаю проектам. Так что скорость будет черепашья, но хоть что-то.

Какие советы будут? Отказаться от отдыха вообще считаю неправильным, выгорание знакомо и так. Жертвовать учёбой ради проектов тоже не уверен, что стоит, но и проекты хочется развивать 😷

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

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

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

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

​Поиск работы

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

С тех пор я ни разу не искала работу, она сама ищет меня. Каким образом? Однажды, еще в мои доайтишные времена я прочитала в фейсбуке одной знакомой такой совет: «вот вы жалуетесь, что не можете найти работу, а сколько раз можно повторять - заведите уже профиль на linkedin». И хоть мне особо нечем было похвастаться в своем профиле, и хотя я и не искала работу, я всё же его завела и с тех пор периодически вношу туда изменения - записи о новом месте работы, новые скиллы, которые я освоила и так далее.

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

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

После того, как в моём linkedin вместо одной не очень известной компании появилось название этой известной компании, произошел какой-то фурор: рекрутёры стали приходить толпами. Практически каждый день там кто-то предлагает работу. Заходить туда регулярно мне лень, тем более, что для этого нужен VPN, так как доблестный роскомнадзор закрыл доступ на linkedin в России (если что, в браузере Opera есть встроенный vpn). Поэтому я захожу раз в месяц, добавляю в контакты всех рекрутеров, кто прислал приглашение (их уже у меня там наверно штук 500), и на каждое сообщение вежливо отвечаю, мол спасибо за предложение, но я сейчас работу не ищу. Пишут там не только из российских компаний, были предложения из Нидерландов, Германии, с Кипра и США.

Конечно, письмо от рекрутера - это еще не гарантия трудоустройства, но тем не менее пока у меня нет ощущения, что мне угрожает безработица.:)

Что я сделаю, если захочу поменять работу? Можно пойти пассивным путем и ответить кому-нибудь из рекрутеров, что я готова принять участие в собеседовании. А можно сделать и более дерзко, опубликовать пост в духе: «Всем привет! А я тут работу ищу…» - но правда во втором случае, боюсь, рекрутеры налетят как птицы в фильме Хитчкока.

Ваша покорная слуга дала интервью учителю информатики для её проекта, и вот что из этого получилось:
🔽🔽🔽

​​Продолжаем знакомиться с IT профессиями😊

Взяла интервью у Елены, автора канала Программирование для гуманитариев: @it_human


❓ Как называется ваша профессия?

Разработчик ПО

❓Каков график вашей работы?

Графика как такового нет, особенно в условиях удалённой работы в связи с пандемией.
Работаю днём ориентировочно 6-8 часов в день, иногда больше.

❓Есть ли перерывы во время работы?

Да, когда я не забываю их себе устраивать.

❓ В чём заключаются основные принципы вашей работы, чем вы занимаетесь?

Есть 2 основных направления:

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

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

❓Мог бы школьник, выпускник, работать по вашей специальности при минимальной подготовке?

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

❓Какие предметы в школе стоит изучать более внимательно для вашей профессии?

Информатику, очевидно, и, думаю, английский язык. Математику тоже не стоит игнорировать, но средних знаний должно хватить.

❓В каком программном обеспечении необходимо разбираться?

Нужно уметь работать с Linux, и желательно с Docker. Для работы с кодом нужен git.
Также нужно разбираться в базах данных (например, с PostgreSQL).
Для настройки серверов пригодится Ansible.
Хорошо уметь работать с Grafana (на ней мы смотрим графики, по которым понимаем, что всё работает правильно, или наоборот - сломалось).


❓Приходится ли вам проходить дополнительные обучающие курсы для повышения качества вашей работы?

Я изначально училась только на курсах, поэтому слово "дополнительные" ко мне не очень применимо. 🙂

❓Как часто вы ищете информацию в интернете по работе?

Примерно 90% рабочего времени

❓ Насколько важны компьютер, телефон и другие гаджеты в вашей работе?

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

❓Как вы думаете, сможет ли робот или искусственный интеллект заменить вас, если да, то через какое время?

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

❓ В каком диапазоне находится ваша зарплата?

150-200 тыс рублей

💻⌨🖥⌨💻⌨🖥⌨💻⌨🖥

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

Подробно о том, в чём разница между программистом и разработчиком ПО читала тут

Зарплата по России

от 40 до 200 тыс. руб

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

А почему тогда в гайдах переменные называют var1, z/y/x?

Это был вопрос к моему посту о том, что переменные в 1 букву - это плохой стиль.
Почему в гайдах встречается такое? Потому что там приведены небольшие учебные примеры, для разъяснения материала.
А в коде настоящих проектов так не стоит делать.

#плохойкод

Магические строки

Продолжаем разбираться с тем, какой код писать НЕ стоит.

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

Сегодня поговорим о магических строках или строковых литералах в коде.

Пример:
if (name == "alligator")

Вот эта строка "alligator" - и есть магическая.

Что с ней не так, спросите вы? Если это единственное место в коде программы, где она встречается, то, в принципе ничего особо страшного в ней нет.

Но представьте, что вот таких if (name == "alligator") в коде много, и эта строка повторяется в разных местах, скажем, раз 10.
Что тогда может пойти не так? Например, в одном месте вы напишете по ошибке aligator, в другом aligater, в третьем alligator - и синтаксически код будет верным, но он будет давать неправильные результаты в ряде случаев, где вы опечатались. И придется проверять в 10 местах, правильно ли там написана строка.

Или, к примеру, вы используете ctrl + C, ctrl + V - копируете и вставляете этого аллигатора в разные места в коде. В итоге если вы ошибетесь в начале, то 10 раз вставите в код неправильные значения, и потом придется 10 же раз заменять на верные (да, современные текстовые редакторы позволяют это сделать достаточно легко, но зачем, если этого вообще можно избежать?).

Как сделать по-другому? Как и с магическими числами - заведите константы для таких строк. 1 раз в коде программы объявите константу:
ALLIGATOR = "alligator"

Используйте везде в коде эту константу:
if (name == ALLIGATOR)

Если вы ошиблись в строке «alligator», и её надо на что-то исправить - её придётся исправлять ровно 1 раз, в 1 месте - там, где вы объявляли константу, и всё.

В других местах кода незамеченных ошибок не возникнет. Если по ошибке написать, например,
if (name == LIAGITATOR)
- код не запустится, и интерпретатор (или компилятор) выведет ошибку о том, что переменная LIAGITATOR не существует. И так баг будет исправлен на самой ранней стадии, и не проскользнёт незаметно в продакшен.

Что такое классы

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

Предположим вы пишете код, где нужно как-то использовать данные пользователя: возраст, телефон, имя итд. Для этого нужны такие переменные:
user_age, user_phone, user_name

А если пользователей 2 или более, переменных стновится в 2 раза больше:
user1_age, user2_age, user1_phone, user2_phone…

В общем, код превращается в какую-то кашу.

Для удобства нам тут не хватает отдельного типа данных для всех юзеров - User.
И для этой цели была придумана такая сущность как struct, структура - она есть в C, Go и некоторых других языках.
struct позволяет хранить вместе те переменные, которые связаны (например, относятся к одному и тому же юзеру).

Ниже - пример на каком-нибудь условном си-подобном языке (это псевдокод, не настоящий код)

struct User {
string name;
int age;
string phone;
}

Так мы будем все данные для одного юзера группировать вместе. Например, создадим два пользователя с разными данными:
struct User user1 = {"Маша", 15, "+79161234567"};

struct User user2 = {"Пётр", 23, "+79167654321"};

В итоге у нас в коде не 6 переменных, а 2 - user1 и user2. А «внутри» каждого такого объекта хранятся все нужные данные, и мы можем их получить вот так: user1.name, user2.name.

А что же такое класс? Класс - это тоже тип данных, примерно как struct, только более расширенная версия. В классах хранятся не только сами данные (как в структурках), но и - методы (функции) для работы с этими данными.

Например:

class User {

string name;
int age;
string phone;

function say_hello() {
print(«Hello! My name is {name}»);
}

Таким образом, мы можем не только хранить в классе информацию об имени, возрасте и телефоне юзера, но и использовать метод класса say_hello:
user1.say_hello()
>> Hello! My name is Маша

user2.say_hello()
>> Hello! My name is Пётр

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

https://t.iss.one/rosfemnadzor/2576

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

Сначала люди начитаются про якобы существующий патриархальный ад в IT, а потом мне в бота прилетают вопросы в духе «а как вы справляетесь с сексизмом в IT», «а вы страдаете от токсичной маскулинности мужского коллектива в IT»?

Еще раз повторюсь: с сексизмом в IT лицом к лицу я не сталкивалась, и лично от него не страдала. (Не берусь утверждать, что никто другой с ним не сталкивался, я говорю только о своем опыте).

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

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

Зато я могу тут привести слова одной знакомой девушки-айтишницы, которая успела поработать и в США, и в России. По её опыту, сексизм и предвзятось в отношении к женщинам в корпоративной культуре США выражена гораздо сильнее, чем у нас, в России. И связать это можно в частности с тем, что в США есть общественные силы, которые давят на работодателей и обязывают их брать на работу женщин - вот эти все квоты, позитивная дискриминация и так далее. А когда людей заставляют что-то делать - это всегда вызывает раздражение и протест. Это раздражение и протест уже в свою подогревают сексистские настроения, только в скрытом виде. И в результате если у работодателей есть возможность безнаказанно и незаметно проявить дискриминацию в адрес женщин (скажем, отказать ей в работе) - для них это соблазн, своего рода запретный плод. Вот такой вот парадокс.

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

Вернёмся к нашим классам.

Что такое классы я рассказывала в этом посте. Если у кого-то остались вопросы по тому посту, присылайте их в бота.

Итак, на этом этапе будем считать, что класс - это описание типа данных
(пример на псевдокоде):

class User {

string name;
int age;
string phone;

function say_hello() {
print(«Hello! My name is {name}»);
}
}

Для нас этот значит, что существует такой тип данных как User, у него есть такие атрибуты как имя (name), возраст (age) и номер телефона (phone). А еще у каждого объекта User можно вызвать метод say_hello, тогда на экране высветится приветствие и имя этого юзера.

Класс - это некий шаблон, трафарет, с помощью которого мы создаём объекты нужного нам типа (объекты = экземпляры класса). Так как же создать объект с помощью класса?

В некоторых языках, например в Java и C++, объекты класса создаются с помощью ключевого слова new.
Создадим двух юзеров:

user1 = new User()
user2 = new User()

В Python мы просто используем имя класса и скобки:

user1 = User()

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

В C++ и Java метод-коструктор называется так же как сам класс, например (это всё еще псевдокод):

class User {

string name;
int age;
string phone;

// метод-конструктор
function User(user_name, full_age, phone_number) {
name = user_name
age = full_age
phone = phone_number
}
}

И теперь мы можем с помощью этого конструктора создавать объекты класса уже с данными:

user1 = new User("Катя", 19, "9169989999")
user2 = new User("Петя", 8, "9161234567")

А в Python в качестве аналога конструктору мы используем метод init:

class User:

def __init__(self, user_name, full_age, phone_number):
self.name = user_name
self.phone = phone_number
self.age = full_age

user = User("Anna", 42, "9161234567")

Первый аргумент self в Python обозначает сам объект (то есть новый юзер, которого мы создаем при вызове функции).
Например, self.name = user_name - значит присвоить объекту поле name со значением user_name.

В некоторых других языках с похожим смыслом используется ключевое слово this. Например, в Java конструктор может выглядеть так:


public class User {

string name;
string number;
int age;

public User(String user_name, int full_age, String phone_number) {
this.name = user_name; // this здесь не обязательно использовать, привожу для аналогии с self
this.age = full_age;
this.number = phone_number
}

}

И напоследок: вернемся к самым первым примерам, где мы создавали объекты классов, но в самих классах не написали метод-конструктор, вот эти user = new User(). В таких случаях при создании объектов всё равно вызывается неявно метод-конструктор - он называется конструктором по умолчанию и в нём не используются аргументы. И если мы не определили его в коде сами, его за нас создаёт компилятор, сам.

Как стать программистом

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

Думаю, у кого-то примерно так и происходит, но давайте смотреть правде в глаза: такие ожидания вряд ли помогут вашему успеху.

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

Вот так же и с написанием программ. Ты уже начал изучать какой-то язык программирования? Отлично - садись и пиши программы. Да, знаю - сложно, непонятно, я не умею, не знаю, у меня лапки. Тем не менее, надо довести дело до конца - написать программу. У меня, думаете, нет лапок? У всех лапки. Но айтишник - это такой человек, который, несмотря на лапки, доводит дело до конца.

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

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

Вот так становятся айтишниками, а не в бесконечной прокрастинации и ожидании прозрения.