Программирование для гуманитариев

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

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

#вашивопросы Если у меня уже есть довольно большой стек технологий, стоит ли записываться на вакансии просто QA-тестировщика (например) или что-то оч низкой планки такой по отношению к стеку из-за страха, что не справлюсь? Подробнее про стек: Ну из основных, из языков и фреймворков, технологий, которые я знаю я знаю, ну мой стек т.е.: Python (довольно хорошо себя чувствую), Java (очень хорошо знаю), JS (начинаю учить), C++ (средне знаю, но постоянно подтягиваюсь в плюсах конкретно сейчас), SQL (средне), TypeScript (начинаю учить, но т.к. это как жс, то будет, думаю, проще), C# (начинаю учить, но схожесть с плюсами и джавой облегчают изучение неплохо так) […] Ниже еще полстраницы навыков и скиллов, опускаю для краткости. Дальше автор вопроса спрашивает, стоит ли ей идти в тестировщики или например в техподдержку. Я в этом вопросе вижу большой страх искать работу разработчика, и этот страх заставляет человека прокрастинировать поиски и всячески от них уклоняться, в том числе искать обходные пути - например, устроиться на другую должность. При этом мы все склонны рационализировать свой страх, то есть придумывать кучу «рациональных» и «разумных причин» не делать то, чего мы боимся. Бесконечная учеба и перфекционизм тоже может быть видом прокрастинации. У вас уже огромный список скиллов, даже для не новичка. Я не знаю, насколько глубоки знания каждой технологии у вас, но «в ширину» список впечатляет. И на этом этапе мне уже не совсем ясно, зачем продолжать расширять этот список, вместо того, чтобы идти и применять свои знания. Просто в качестве хобби? Или всё же учеба - это способ прокрастинации? Чтобы преодолеть страх, нельзя позволять ему принимать решения за вас и вести куда-то за собой. Идти нужно туда, где страшно. Страх поначалу никуда не денется, так что придется просто нести его с собой. :) Чтобы было развитие, нужны задачи чуть сложнее, чем вам было бы комфортно. Если делать только то, что привычно и легко - никакого роста и не будет. Отвечая на вопрос: в QA идите в том случае, если вы планируете карьеру тестировщика, а не разработчика. В техподдержку вообще не ходите, там не нужна техническая подготовка - это чаще всего вакансии без особых требований к техническим знаниям и скиллам. Хочу, чтобы по времени такая реальная работа не занимала всё время, т.к. хочу продолжать изучать много чего ещё из своего чек-листа для себя и ещё заниматься совместно с друзьями проектом/начать делать свой один. И помимо просто изучения языков и прочего для себя из своих планов, я сплю около 13-15 часов, чтобы чувствовать себя хорошо + ещё общаться просто с друзьями и заниматься чем-то своим за день нужно. Ну то есть, я не выхожу никуда из дома почти никогда, но при этом времени у меня сейчас итак не особо много и много чего делать нужно. Что касается желания иметь много свободного времени, я сомневаюсь, что реально всё вот так совмещать, как вам бы хотелось. С full-time работой, вероятнее всего, так не получится. Всё же работа диктует свой график, и работодатели не станут подстраиваться под вас. Но раз у вас есть желание усидеть на двух стульях (то есть учиться, работать и иметь кучу свободного времени) - поищите какие-нибудь стажировки с частичной занятостью, скажем на 2 дня в неделю. И хочу именно удалёнку, нет, я знаю, что поначалу лучше не работать удалённо, но у меня проблемы в общении голосом, а предпочтение текстом/с трудом в дисе том же или ещё где общаться в принципе могу, ну и ещё времени жалко и сидеть в офисе это в принципе для меня ад, я не люблю работу в дефолтном её понимании как офисную и потом домой идти, просто ненавижу подобное. Про удалёнку - опять-таки - тут всё зависит от готовности работодателей вам предоставить именно такую работу. Если сможете найти именно такой идеальный для вас вариант - хорошо. Но будьте готовы, что условия игры на начальном этапе диктует работодатель. Задать вопрос автору блога можно здесь: @hum_it_bot

​Стать программистом за 3 дня «Невозможно», — могли подумать вы и были правы. Нельзя стать программистом за 3 дня, но разобраться, как устроен мир разработки и сделать к нему первые шаги — вполне реально. На бесплатном трехдневном курсе Нетологии «Как стать программистом» вы узнаете, чего ждать от профессии разработчика, подходит ли она вам и как сделать самое сложное — начать. Сделайте первый шаг к большим возможностям, а мы поможем двигаться дальше ↓ https://netolo.gy/heN

[Ответ на вопрос из поста выше] ...Если я верно поняла, проблема заключается в том, что у вас слишком дробные, разрозненные задачи. По сути это ключевое отличие джуниор-разработчика от миддла и выше: джунам часто дают какие-то мелкие кусочки задач, и часто даже не разъясняют, какой более большой цели это служит (и это не совсем грамотный подход). То есть, пример формулирования задачи для джуна: «Добавь в базу данных таблицы user новый столбец last_seen_at, дата самого последнего посещения». И всё. Никаких разъяснений - зачем нужен этот столбец? Как он будет использоваться? Какую задачу это решает? Просто вот тебе задача, выполняй. То есть, дают коммуникацию, что делать, и как это делать, но не объясняют, зачем. Я не знаю, похоже ли это на ваш случай, подумайте об этом. Пример задачи для специалиста middle и выше: «Если пользователь не посещал сайт больше недели, мы хотим присылать ему Push-уведомление о том, что для него действует персональная скидка.» Дальше разработчик уже декомпозирует задачу (один или вместе с коллегами), и придумывает сам, как он это будет делать. В частности, он решает, что в базе данных нужно хранить дату последнего посещения сайта пользователем. Но это лишь одна из подзадач. То, что в одной задаче вы работаете с БД, в другой с фласком, в третьей еще с чем-то - это не особо проблема, на мой взгляд. В будущем вам бы хорошо прийти в ту точку, где в одной задаче вы будете работать одновременно и с базой данных, и с Flask, и возможно еще с несколькими технологиями - всё это всего лишь инструменты, важно уметь их подбирать так, чтобы они решали поставленную задачу. Если использовать метафоры, то задача для джуна (причем так себе сформулированная) - это «возьми молоток и ударь по этому гвоздю». Задача для зрелого специалиста - «собери шкаф». А задача для еще более верхнеуровнего специалиста, например, руководителя - «нам негде хранить бумаги. придумай что-нибудь». Чем круче специалист, тем менее детализирована задача. Теперь к вопросу о том, что вам делать. Думаю, что коммуницировать с руководством. Во-первых, если вам не объясняют, какую задачу вы решаете и для чего вас попросили что-то сделать - всегда задавайте вопросы - зачем это нужно? Какую цель это решает? Получив большие информации, вы возможно сможете предложить решение получше того, которое вам дали на реализацию. Таким образом вы станете более вовлечены в планирование и обсуждение задач, как серьезный взрослый специалист. Во-вторых, просите более крупные задачи, и сформулированные более верхнеуровнево. Такие, чтобы самостоятельно отвечать за гораздо более крупные куски, чем вы привыкли. Если ваши рукводители не стараются из вас вырастить более зрелого специалиста, значит вам нужно брать инициативу в свои руки. А что касается обучения - действительно продуктивнее изучать те технологии, которые вам нужны для решения текущей задачи, чем что-то постороннее. Но и выделить время почитать что-то, укрепить базовые знания - тоже бывает полезно. Задать вопрос автору блога можно здесь: @hum_it_bot

#вашивопросы Есть ли у меня перспективы роста, если в моей компании я делаю очень разноплановые и малосвязанные между собою задачи? Уже восемь месяцев я работаю джуниор-пайтон-разработчиком. Моя компания хорошо ко мне относится, но она очень маленькая, я бы сказала крошечная (8 человек). У меня нет отдельного ментора, но сотрудники в целом охотно отвечают на мои вопросы. В то же время меня смущают две вещи: во-первых, у меня достаточно разные задачи, и большинство из них не связаны между собой. То есть в одном месте я больше с Фласком копаюсь, в другом с запросами в БД, в третьем вообще со стилями в CSS. И я вот замечаю, что за это время работы в компании у меня появился опыт, конечно, и понимание, как работает большая система, но в то же время я не могу сказать, что научилась что-то делать самостоятельно. То есть через несистематичность подхода в задачах (мне дают какую-то поточку, хотя она нередко объемная, и у меня занимает много времени просто въехать в задачу) мне трудно овладеть чем-то и уже за это держаться. И в то же время я бы не хотела учиться в нерабочее время, потому что это мне не кажется продуктивным. Да и даже я не знаю, чему именно учиться: конечно, у меня есть мой чеклист собственных пробелов, но мне сложно допроходить какую-то тему, когда мое текущее задание совсем с ней не связано. То есть у тебя я бы хотела спросить, это проблема в моем подходе — или же проблема компании? Если это проблема моего подхода, что бы ты мне посоветовала для систематизации знаний? Если это проблема в компании, как и что со своей стороны я могу прокомунницировать? Мне просто хочется понять, вообще перспективно ли быть в этой компании — и главным образом меня сейчас знания и навыки интересуют. И так же хочется понять, что если это больше моя ответственность, то как изменить подход. Ответ в следующем посте.

✅ Хотим обратить ваше внимание на полезный telegram-канал для обучения высокоуровневому языку программирования Python На канале ежедневно публикуются задачи по Python и Machine Learning: алгоритмы, функции, классы, регулярные выражения, итераторы, генераторы, ООП, исключения, numpy, pandas, matplotlib, scikit-learn, TensorFlow и многое другое! ✔️Станьте специалистом по Python вместе с каналом "Задачи по Python и машинному обучению"

...Теперь к вопросу о TDD. Постараюсь, как обычно, не закапываться вглубь этой методологии, а пробежаться по верхам. Основное в TDD - тесты мы пишем до того, как пишем/меняем код самой программы. И очень часто их запускам - после любого изменения программы. Приведу пример. Нам нужна функция, которая будет считать стоимость товаров в Интернет-магазине. Нам известна номинальная стоимость товара, но реальная стоимость будет посчитана по какой-то хитрой формуле. Для простоты предположим, что в нашем магазине все товары продаются по цене в 2 раза большей, чем их номинальная стоимость. Наша будущая функция будет называться calculate_price() и она будет принимать как аргумент номинальную стоимость. Начнём с элементарного теста для этой функции. Если товар стоит 100 рублей номинально, мы его будем продавать за 200. Если он стоит 0, то и цена будет бесплатной: def test_calculate_price(): assert calculate_price(100) == 200 assert calculate_price(0) == 0 После этого напишем саму функцию. В целях демонстрации она будет максимально простой: def calculate_price(nominal): return nominal * 2 Теперь мы можем запустить тест, и он отработает как нужно, если, конечно, мы нигде не ошиблись. Первая версия программы готова. Внесение изменения Предположим, через какое-то время нам не нравится код нашей функции, и мы решили переписать его более красиво. При этом все цены должны остаться такими же. Тут мы должны помнить, что даже минимальное изменение в коде может сломать программу. Даже когда мы уверены, что точно нигде не ошиблись. После каждого минимального, микроскопического изменения в коде calculate_price, мы заново запускаем наш тест, и проверяем, не сломали ли программу. Обнаружен баг Один покупатель в нашем Интернет-магазине оформлял заказ, и увидел, что товар стоит -200 рублей. Так мы узнаём, что наша функция может возвращать отрицательные значения. С чего мы начнем исправлять эту ошибку? Поменяем функцию calculate_price ? Нет, первым делом нужно доработать тесты. Раз в программе есть баг, значит тесты должны его отлавливать. Предположим, мы хотим, чтобы наша функция возвращала None, если мы передаём ей отрицательную номинальную цену. Добавим в наш тест проверку на работу с отрицательными числами: def test_calculate_price(): assert calculate_price(-100) is None Теперь запускаем этот тест, чтобы убедиться, что он возвращает ошибку. Если тест не падает, а баг есть, значит тест написан неправильно и надо его переписать. Затем мы переписываем уже саму функцию и снова запускаем тест - на этот раз тест должен завершиться без ошибок. Изменение логики функции Предположим, цены в нашем магазине изменились, и теперь все товары стоят в 2 раза больше номинальной стоимости + наценка 20% от номинальной стоимости. Что мы поменяем первым делом, чтобы реализовать эту логику? Правильно, тест. def test_calculate_price(): assert calculate_price(100) == 220 # и так далее Запускаем тест, убеждаемся, что он возвращает ошибку, и переделываем саму функцию, чтобы она теперь считала стоимость по-новому. Вот так примерно выглядит разработка по методике TDD.

TDD или зачем писать тесты TDD расшифровывается как test driven development, разработка через тестирование. Что это такое расскажу ниже, для начала пара вводных слов о самих тестах. Прежде всего, что такое тест? Тест - это код, который проверяет, что наша программа работает правильно. Думаю, любой без исключения разработчик хоть раз в жизни ленился писать тесты. А новички часто и вовсе сомневаются, что тесты нужны, но это потому что они еще не успели наступить на грабли и убедиться на собственных ошибках, что без тестов ошибки бывают гораздо больнее, чем с ними. Когда мы ленимся написать тест, мы делаем так, потому что нам кажется, что в нашей программе нет никаких ошибок. И мы доверяем этому «кажется». Но представьте, что будет, если, например, при создании лекарства его создатели будут полагаться это чувство: «нам кажется, лекарство не вредное и работает», а клинических испытаний проводить не будут. Или если создатели самолётов будут просто верить, что «он летает», и никак это не проверять. С программированием риски часто не настолько высоки, от многих программ не зависит ничья жизнь, но и тут ошибки могут привести к тому, что, например, у пользователя спишут со счета неправильную сумму денег, а это уже неприятно, и за такую работу вас никто не похвалит. Поэтому с кодом, по большому счету, мы поступаем так же, как с лекарствами: только после испытаний мы можем утверждать, что код работает.

Локалка | Статьи для IT-специалистов - сохраняем лучшие статьи по программированию и администрированию в удобном для чтения формате @Local_Area_Network

Сложности работы «на удалёнке» Мне тут пришла идея делиться с вами не только своим личным опытом, но и рекомендациями, которые я слышала от моих коллег, мнению которых я доверяю. Сегодня как раз такой случай. Речь пойдёт о работе на удалёнке. В нашей компании…

#вашивопросы Проходили ли вы CS50 и курс по питону одновременно, или сначала закончили один, а потом начали другой? Если одновременно, не приходилось ли бороться с путаницей в голове из-за разницы между C и питоном? Ну вообще я сначала проходила пару мелких курсов по питону, потом начала CS50, потом забросила его, потом вернулась к нему через полгода и уже прошла полностью. И перед ним, и после я проходила что-нибудь, связанное с питоном. Путаницы в голове у меня не было, скорее было некий культурный шок, потому что Python гораздо проще, чем Си, и о многих аспектах программирования при знакомстве с ним можно даже не задумываться (например, о работе с памятью). После знакомства с Си, я поняла, что и в курсе по Пайтон тоже что-то рассказывали про память и про ссылочные типы данных, но я эту информацию фактически пропустила, так как не было понимания, зачем она на том этапе нужна. А вот после Си стало понятно, зачем, и появилась привычка проявлять более глубокий интерес к устройству языка, не ограничиваясь его синтаксисом. Если у вас возникает путаница в голове, то попробуйте больше сравнивать 2 языка друг с другом и, возможно, даже выполнять одни и те же задания на обоих языках по очереди. У Python тоже Си-подобный синтаксис, просто нужно запомнить, какие конструкции в Си обозначаются по-другому в Python. Например, там где в Си используются фигурные скобки { }, в Python чаще всего идёт двоеточие : и отступы на следующей строке. И второй момент, о котором стоит себе напоминать - язык Python фактически написан на Си (точнее, на си написан самый распространенный интерпретатор для Python, CPython, но в этом контексте это уточнение не так важно). Так что можно считать, что Си - это как бы «нижний слой» питона, то, что у него под капотом. И, изучая, например, структуры данных в Python, можно заодно поинтересоваться, как они написаны, и на каких структурах языка Си основаны. Например, list в Python основан на массивах в Си, с некоторыми дополнениями и удобными методами. Поизучайте массивы и списки в Python, и проанализируйте, чем они отличаются, и чего язык Python добавил нового в концепцию массивов, чтобы упростить нам, пользователям, жизнь. Возможно, при таком подходе эти два языка будут для вас восприниматься как части единой системы, а не как два разных иностранных языка. Задать вопрос автору блога можно здесь: @hum_it_bot