Нужен ли линукс для бэкенда
Обновлено: 04.07.2024
Некоторые новички считают, что достаточно выучить нужный язык программирования — и всё, это знание по умолчанию делает из вас отличного бэкендера. Помните подход «купил зеркалку — стал фотографом»? Но это далеко не так.
Меня зовут Лера Солодовникова, я продакт-менеджер на программе «Python-разработчик» в Яндекс.Практикуме, сегодня хочу обсудить необходимые для работы бэкендера смежные знания и умения. По большей части текст ориентирован на Python-разработчиков, но пригодится и тем, кто работает с другими языками, — принципы довольно общие, разница лишь в инструментах.
Ещё в посте — отношение различных компаний к вашим навыкам, их важность для прохождения собеседования, а также подборка полезных книг по теме.
Базис
Начнём с главного — с ОС. Хороший бэкендер должен быть знаком с unix-подобной операционной системой. Это могут быть не только разные Linux-дистрибутивы, но и macOS или FreeBSD, но общепринятым стандартом всё же является Linux. Работать вы можете на ПК или ноутбуке с любой ОС, но Linux нужно знать. Ведь вам придётся довольно активно взаимодействовать с серверами, а большая часть из них работает на Linux.
3–5 декабря, Онлайн, Беcплатно
Из этого пункта плавно вытекает второй — работа с командной строкой. Это нужно для того, чтобы говорить с сервером на его языке. Нужно не просто знать, как нагуглить ту или иную команду и что она делает, а разбираться в командном интерфейсе. Опять же, допустимы варианты в зависимости от личных предпочтений или литературы, по которой вы учились: zsh, bash, fish, но стандарт — bash.
Следующее требование ― знание систем контроля версий. И тут уже без особых альтернатив: нужен именно Git, несмотря на наличие выбора. Изучите сам Git и механику взаимодействия с ветками, если собираетесь работать в команде. Впрочем, если вы интересуетесь бэкенд-разработкой и сейчас читаете этот текст, аккаунт на GitHub у вас уже наверняка есть (а если нет, вы знаете, что делать).
Дополнительным преимуществом для начинающего бэкенд-разработчика будет знание хотя бы одного веб-фреймворка — для Python это Django или Flask. Плюс базовые знания SQL. Никто не будет выставлять вас на ежемесячные соревнования SQL-программистов, но важно уметь самому проектировать БД, работать с ними через ORM, если мы говорим про Django, или через SQLAlchemy в случае с Flask.
Ну и, конечно, никуда без основ администрирования сервера, хотя бы на уровне «Я могу сам задеплоить свой проект по SSH, не отвлекая коллег от чтения Хабра».
Алгоритмы и тестирование
В плане базовых требований к кандидату и знания основ профессии компании делятся на два лагеря.
В первом сидят серьёзные практики, которых волнует только то, что вы умеете делать. У вас может быть любое образование, и, если вы докажете им, что на текущем жизненном этапе вы в состоянии выполнять все задачи, которые они взвалят на бэкендера, вы в деле.
Второй лагерь более требователен — для них важны фундаментальные знания. Техническое образование, математическое мышление и знание алгоритмов — вот тот набор, с которым надо заходить в такие компании. Например, в Яндексе без алгоритмов никуда. Послабление могут сделать в плане самого образования — оно тут как дополнительный плюс, потому что бывают ситуации, когда человек обладает такими знаниями, даже не обучаясь этому в вузе: самоучек много и курсов тоже.
Если вы хотите в Яндекс, то самое важное, на что будут смотреть HR и на техническом собеседовании — это на результаты прохождений самих секций собеседования и на то, насколько вы знаете алгоритмы. Ваш диплом и название вуза здесь как вишенка на торте. Вишенки может и не быть — без неё торт не перестанет быть тортом.
Примерно такое же отношение у работодателей к тестированию. Кто-то уверен, что джун должен заниматься тестированием, и это будет чуть ли не первым вопросом на собеседовании. Кто-то замечает, что для тестирования есть тестировщики. Кто-то вообще ничего не тестирует.
Что работодатели ждут от Junior Python-разработчикаGitHub и хакатоны
Иногда в комментариях к подобным постам встречаются теории о важности наличия у кандидата прокачанного профиля на GitHub или опыта участия в хакатонах. Ваши проекты на GitHub, множество коммитов и форков, килограммы бейджиков с IT-конференций и хакатонов — это дополнительный фактор вашей оценки как специалиста.
Прежде всего на собеседованиях смотрят на практическое решение конкретных задач в рамках прохождения секций. Иногда дополнительно могут посмотреть ваш проект на GitHub, иногда — нет. Если вы идёте на мидла, то хакатонский опыт поможет вам быстрее и легче проходить секции собеседования. Для джуна опыт участия в хакатонах, даже без призовых мест, будет реальным подтверждением того факта, что человеку интересна профессия, он старается быть в курсе новых решений и инструментов, пытается самостоятельно прокачивать навыки. Да, это тоже плюс.
Командная работа
Про soft skills написано множество постов и, скорее всего, несколько книг, поэтому я не будут сильно вдаваться в их важность и необходимость — вы всё это уже читали много раз.
На мой взгляд, главное — уметь работать в команде. Это не значит, что условный интроверт не справится, никто не требует от вас быть душой компании и зажигать на тимбилдингах. В этом пункте речь о способности задавать вопросы. Вы не представляете, сколько проблем в проектах бывает связано с тем, что человек просто вовремя не спросил, не уточнил, не сообщил коллегам, что заметил потенциальный баг.
Разговаривайте, спрашивайте, уточняйте. Это нормально. Так же нормально, как пойти и усердно погуглить что-то, если не получается.
Говоря об отношениях в команде, стоит упомянуть дедлайны. Их важно соблюдать, особенно если они командные. Ситуации, в которых кто-то один просто забыл что-то сделать или не успел (и не сказал об этом), часто заканчиваются тем, что у всей команды съезжает график. Как это отражается на отношении к человеку, регулярно срывающему сроки, вы и без меня знаете.
Ещё несколько советов. Спокойно реагируйте на критику и замечания, прокачивайте уровень самоорганизованности, давайте коллегам обратную связь, не бойтесь ошибаться в работе и исправлять ошибки. И учитесь — возможностей для этого сейчас множество.
Полезные книги
Марк Лутц, «Изучаем Python». Марк написал эту книгу по мотивам собственных курсов, которые ведёт уже более 10 лет. Здесь всё важное: обзор инструментов, типы объектов, функции плюс описания моделей и инструкции по обработке исключений.
Антонио Меле, «Джанго 2 в примерах». Книга делает упор на практическое создание приложений для реальных задач. Кроме непосредственной работы с компонентами самого фреймворка, рассматриваются также и возможности интеграции сторонних инструментов.
Лекции Тимофея Хирьянова по алгоритмам. Тимофей — один из преподавателей МФТИ. Лекций по алгоритмам множество, но эти наглядные. Особенно полезны для новичков, но и разработчику с опытом тоже пригодятся.
Если вы можете свободно читать профильную литературу на английском, то порекомендуем ещё и пару книг о разработке на основе тестов: Harry Percival, «Test-Driven Development with Python» и Kevin Harvey, «Test-Driven Development with Django».
Хотите улучшить этот вопрос? Переформулируйте вопрос так, чтобы на него можно было дать ответ, основанный на фактах и цитатах.
Закрыт 5 лет назад .
Порог вхождение немного выше чем в вин, нужно думать и т.п
Но я готов полностью разобраться, только если оно того стоит. про бесплатный софт и то что можно слепить все что хочешь я прекрасно понимаю.
Я прочитал много статей в интернете на эту тему, и почти везде вода водой, переливают пустое в порожнее. Буду благодарен за конструктивные ответы.
на самом деле, для разработчика, вопрос выбора операционной системы вовсе не так субъективен, как может показаться.
А если учитывать, что 67% веб-серверов используют Unix, выбор становится еще менее субъективным и, очевидно, диктуется:
а) требованиями рынка для данной конкретной специальности
б) техническими преимуществами для данной конкретной специальности
Если вы точно собрались в бэкэнд - имеет смысл выбрать линукс, поскольку существует объективное преимущество: под юниксы гораздо проще, например, собрать какой-нибудь нестандартный модуль для php/python.
Еще пример: билды python-модулей для Windows. Поскольку сейчас бэкэнд это зачастую не только выдача контента, но и data science, зависимость от таких билдов абсолютно недопустима (да и неудобна)
С выходом слоя совместимости с Linux в десятке это преимущество, возможно сойдет на нет, но тогда вы просто учите Linux, находясь в Windows. И кроме того, нужно посмотреть, легко ли профилировать/дебажить находясь в этом слое совместимости, работают ли там юниксовые strace и другие низкоуровневые инструменты
кроме того, до недавних пор Windows не мог нормально работать с симлинками. Если в проекте используются симлинки - хана. Сейчас вот, говорят, стало лучше, но я не проверял.
и, конечно, я забыл о кастомных демонах. если вы попадете в контору, которая использует линукс на продакшене и которая пишет демонов на c/c++, к которым обращаются php/python/ruby/node.js то, с вероятностью 100%, они будут разрабатывать их только под линукс, под win вы их просто не соберете.
ну и да, опыт работы с линуксом пригодится, когда вы будете участвовать в деплое.
повторюсь - все это касается только разработки бэкэнда (слегка - андроида, поскольку андроид - это linux)
P.S. когда вы научитесь спокойно работать в терминале, у вас будут хостинги, ssh-доступы, горы виртуалок и т.д., вы всегда можете перейти на винду, но чисто педагогически - на период обучения - по крайней мере, я бы выбрал ту систему, с которой предстоит работать.
P.P.S. вынесу из комментов: - "не настолько сложно компилировать" - это как раз очень субьективно. если у вас стоит php под MSVC - а это дефолтная сборка, вам придется добыть MSVC и разбираться с ним. Вы ставили когда-нибудь MSVC? под линукс сборка php выполняется очень просто.
На моей текущей работе достаточно серьезный и большой отдел машинного обучения и если мне придется ставить виртуалку для того, чтобы компилировать python-пакеты под линукс, производительность упадет. поэтому на работе - линукс.
Я не говорю, что win зло, просто если на рынке 67% серверов работают под Unix, а вы ищете работу в бэкэнде. ну. ОС - это всего лишь инструмент, сейчас мы его и выбираем. Если бы автор спросил про разработку игр для Xbox - я бы голосовал за винду.
"Далеко не все ими пользуются" и "я этим не пользуюсь, потому что у меня винда" - это не ответ на собеседовании, и это не решение для рабочих вопросов.
Какие еще могуть быть основания для выбора оси? Если вы ее для работы используете - берите то, что лучше подходит для работы, если для игр - берите то, что подходит для игр. Мы в данном случае говорим о работе, конкретно о бэкенде. На этот вопрос я и отвечал.
P.P.P.S некоторые пункты, из моего ответа справедливы и для OSX/MacOS. Хотя OSX - это Unix, но практические проблемы при работе с бэкэндом встречаются и там тоже. Как минимум, убогая - пока что - поддержка докера - через VirtualBox, как и на винде
P.P.P.P.S добавлю еще один пункт - если вы собираетесь работать в маленькой веб-студии - то смело идите с виндой. если google/yahoo/yandex/mail/rambler - смотрите здесь.
Новость старая, но, по моим наблюдениям, мало что изменилось - бэкенд разработка в коллективе в больших конторах в основном ведется под linux/bsd-osx.
С точки зрения именно UI/программ для разработки - никакой разницы между Windows/Linux нет. Большинство серьезных программ, которые используются для бэкенд-дева кроссплатформенны - PhpStorm/NetBeans/Vim/Emacs. А в остальном - когда вы работаете, вы успеваете видеть только IDE/редактор, браузер с открытым проектом + стаковерфлоу, и терминал. Если вы видите что-нибудь кроме терминала/редактора/браузера - значит, вы не работаете.
Пересидел на винде, поставил сейчас убунту. Решил подтянуть свои знания в этой ОС. Что мне следует изучить, что повысить качество своей работы, а так же, чтобы было плюсом при дальнейшем трудоустройстве?
При этом, не очень люблю ковыряться в системе, больше люблю код писать.
Когда захожу на какой-нибудь ЛОР, начинает казаться, что я безмерно тупой — там тебе каждый и ядро пересобирёт, и проблему любую решит без гугла, и код пишет только в vim/emacs, и, вообще, некоторые диалоги там даже не понятны :)
- Вопрос задан более трёх лет назад
- 1671 просмотр
Простой 4 комментария
Мое мнение — и так сойдет, с консолью дружишь и главное. Я работаю только на Линуксе, но тоже не дальше ушел — не сисадмин же, единственное аналитику нагрузки подтянуть нужно: ps/top/htop/atop
Для бекендера нужно знать по больше же пользование командами определенного софта: docker, git, консольные команды фреймворков
Что изучить? Сетевой стек и всё около-сетевое - как линукс работает с сетью.netstat, ping, ssh, ufw, ifconfig и т.д
Для бэкенд разработчика это важно.
собирать из исходников нужно в очень редких случаях, на сколько редких, что знать как это делается вообще не нужно. Так что можно смело отмести этот навык.
Для бекендера надо уметь устанавливать и настраивать тот софт с которым работаешь: nginx, apache, mysql, postgres, redis, mongodb и так далее.
Vim можно вообще не знать, в *nix обычно есть редактор проще, типа nano, joe или вообще mcedit.
Самое главное - научиться выходить из vim прежде чем испортишь файл ;-)
Если работаешь с языком, у которого есть свой пакетный менеджер (npm, yarn, pip) нужно уметь установить его и разруливать ошибки при установке через эти пакетные менеджеры.
Например для python-pip требуются установленные компилятор и заголовочные файлы питона. Имею ввиду, что такие тонкости надо знать.
ssh само собой надо уметь настраивать, генерация ключей, настройка авторизации по ключу, копирование файлов scp.
git настраивать bare-репозитории чтобы заливать на сервер и там же разворачивать, при работе без сторонних сервисов типа github, bitbucket.
Разные операционные системы длительное время обслуживают различные аудитории: Windows — бизнес-профессионалов, Mac — творческих, а Linux — разработчиков. Разработчикам ОС такой тип рыночного спектра сильно упростил концепцию продукта, технические требования, пользовательский опыт и направление рынка. Однако, он также ужесточил нормы рабочего пространства, что деформировало отдельных пользователей под узкие, непересекающиеся области: у бизнесменов нет возможности заглянуть в творческий процесс, а у разработчиков нет представления о проблемах бизнеса.
Для современных бизнес-аналитиков особенно актуален вопрос ликвидации пробела между бизнесом и разработкой. Бизнес-аналитики должны быть двухплатформенными, способными использовать командную строку, доступную только на Linux (или в macOS), но при этом уметь извлекать широкие возможности из Microsoft Office в Windows. Очевидно, что мир Linux пугает тех, у кого образование в сфере бизнеса. К счастью, как и в большем количестве вопросов, вам необходимо изучить 20% информации, чтобы выполнить 80% работы. Вот мои 20%.
Почему современные бизнес-аналитики должны знать Linux
Благодаря своим open source корням, Linux выиграл от вкладов тысяч разработчиков за всё время его существования. Они построили программы и утилиты, чтобы упростить работу не только себе, но и тем программистам, которые последовали за ними. В результате open source разработка создала эффект сетевой выгоды: чем больше разработчики строили утилиты на оригинальной платформе, тем больше других разработчиков могло влиять на эти утилиты, чтобы писать собственные программы.
В результате получился огромный пакет программ и утилит (то есть софт), который был написан на Linux и под Linux. Большая часть его никогда не портировалась в Windows. Один из примеров — популярная система контроля версий (VCS), которая называется git. Разработчики могли написать софт под Windows, но они этого не сделали. Они написали его для работы в командной строке, для Linux, потому что Linux — экосистема, в которой уже были все необходимые инструменты.
Если вдаваться в подробности, разработка на Windows ведёт к двум основным проблемам:
- Базовые задачи, вроде парсинга файлов, рабочего планирования и поиска текста используются чаще, чем запуск утилиты командной строки.
- Языки программирования (Python, C++) и связанные с ними библиотеки выкидывают ошибки, потому что они ожидают конкретных параметров Linux или специфических локаций файловой системы.
Если собрать всё вместе, это выльется в трату времени на переписывание базовых инструментов, которые уже доступны в Linux, они позволят избежать ошибок совместимости с ОС. Тут нет никаких сюрпризов — экосистема Windows просто не была задумана и спроектирована под нужды разработки софта.
Теперь давайте рассмотрим базовые идеи Linux.
Фундаментальная единица Linux: "оболочка"
Shell (оболочка, также известная как терминал, консоль или командная строка) — это текстовый интерфейс пользователя, через который команды отправляются машине. На Linux, по-умолчанию, язык оболочки называется bash. В отличие от Windows-пользователей, которые в своём большинстве используют навигацию "навести-кликнуть" по окну, Linux-разработчики привязаны к клавиатуре и пишут команды в оболочке. Хоть этот переход далёк от естественного для тех, у кого нет бэкграунда в программировании, плюсы разработки в Linux сильно перевешивают изначальное вложение в обучение.
Изучаем несколько важных концептов
В сравнении с достаточно зрелым языком программирования, bash имеет всего несколько основных концептов, которые необходимо выучить. Как только вы охватите это, остаток bash — простое запоминание. Я переформулирую понятней: хорошо разбираться в bash значит запомнить 20-30 команд и их часто используемые аргументы.
Linux кажется непроницаемым для тех, кто не касается разработки, из-за способа, которым разработчики (не напрягаясь) извергают эзотерические команды терминала, когда им захочется. Правда в том, что они хорошо знают только несколько десятков команд — за всем более сложным они так же (как и все смертные) обращаются в Google.
Опуская мелкие загвоздки, стоящие на пути, вот главные концепты в bash.
Командный синтаксис
Команды соответствуют синтаксису:
Псевдонимы директорий
- Текущая директория (где я?): .
- Родительская директория текущей директории: ..
- Домашняя директория пользователя:
Например, чтобы поменять текущую директорию на родительскую директорию нужно ввести: cd ..
Таким же способом, чтобы скопировать файл, расположенный в "/path/to/file.txt" в текущую директорию, нужно ввести cp /path/to/file.txt . (заметьте, что в конце команды точка). Поскольку это всего лишь псевдонимы, вместо них может использоваться реальное имя пути.
STDIN / STDOUT
Всё, что вы пишите в окне и подтверждаете (с помощью ENTER), называется стандартным вводом (STDIN).
Всё, что программа выводит в ответе в терминал (например текст из файла), называется стандартным выводом (STDOUT)
Конвейер (piping)
Pipe принимает STDOUT от команды слева от pipe и превращает его в STDIN для команды справа от pipe.
Символ "больше" принимает STDOUT от команды слева и записывает/перезаписывает в новый файл справа
пример: ls > tmp.txt
Два символа "больше" принимают STDOUT от команды слева и добавляют к новому или существующему файлу справа.
пример: date >> tmp.txt
Шаблоны поиска (wildcards)
В bash можно написать John* . Если вы хотите вывести список всех файлов в какой-то папке, заканчивающихся на ".json", пишете : ls *.json
Завершение с помощью tab
Bash часто завершает команды сам, по определённой логике, если вы начинаете вводить команду и нажимаете TAB.
Однако, стоит попробовать что-то вроде zsh или fish для автозаполнения, потому что запоминать команды и все их параметры очень сложно. Более того, эти инструменты применят автозаполнение, основываясь на вашей истории используемых команд.
Выход
Иногда вы застреваете в какой-нибудь программе и не можете оттуда выйти. Это очень часто повторяющееся событие для новичков в Linux, которое невероятно демотивирует. Часто выход происходит с помощью чего-то, содержащего q. Хорошо бы запомнить то, что будет написано ниже и использовать, когда вы в ловушке.
Что я помню из команд bash
Это те команды, которые я использую чаще всего в Linux (начиная от самых часто используемых к самым редко используемым). Как я уже писал раньше, знание всего горстки команд поможет выполнять большой набор необходимых программируемых задач.
- cd изменить директорию
- ls -lha вывести директорию в виде списка (подробного)
- vim или nano редактор командной строки
- touch создать новый пустой файл
- cp -R скопировать файл или директорию (и всё их содержимое)
- mv переместить или переименовать файл
- rm удалить файл
- rm -rf удалить файл или папку без возможности восстановления [использовать аккуратно!]
- pwd вывести текущую рабочую директорию
- cat или less или tail или head -n10 вывести в STDOUT содержимое файла
- mkdir создать пустую директорию
- grep -inr найти строку в любом файле этой директории или дочерних директориях
column -s, -t <delimited_file> отобразить разделенный запятыми файл в виде столбцов
ssh @ соединиться с удалённой машиной
tree -LhaC 3 показать структуру директории на 3 уровнями вглубь (с размерами файлов и включая скрытые директории)
htop (или top ) диспетчер задач
pip install --user пакетный менеджер Python для установки пакетов в
pushd . ; popd ; dirs; cd - push/pop/view директорию в стек + изменить обратно на последнюю директорию
tmux new -s session, tmux attach -t session создать новую сессию терминала без создания нового окна [продвинутый уровень]
wget загрузить веб-страницу или веб-ресурс
find <directory> вывести список всего содержимого директории и её дочерних директорий рекурсивно
Продвинутые и не часто используемые команды
Я считаю хорошей практикой хранить список команд, которые полезны в определённых ситуациях, даже если подобные ситуации случаются редко (например, какой процесс блокирует конкретный сетевой порт). Вот несколько нестандартных команд, которые у меня всегда под рукой:
Никогда не останавливайтесь: В программировании говорят, что нужно постоянно учиться даже для того, чтобы просто находиться на месте. Развивайтесь с нами — на Хекслете есть сотни курсов по разработке на разных языках и технологиях
Читайте также: