Тулинг что это в программировании
Путеводитель по программе JPoint 2019
Последний месяц зимы подходит к концу, и просыпается здоровое желание сходить на какую-нибудь большую Java-конференцию. Благо, всего месяц остался до JPoint 2019 — международной Java-конференции, которая пройдёт в начале апреля в Москве. Программа почти стабилизировалась, и настало время раскрыть все карты.
Программа нового JPoint огромная: два дня, каждый день по двадцатке докладов. На какие из них идти? Можно упростить себе задачу, разбив доклады на несколько категорий:
Объем хабрастатьи не позволит рассмотреть все доклады одновременно, поэтому в каждой из категорий я выбрал парочку наиболее интересных лично мне. Про всё остальное можно узнать на сайте, а сейчас можно занырнуть под кат и увидеть, что год грядущий нам готовит.
VM & Runtime
Так сложилось, что именно на JPoint и Joker традиционно делают самые хардкорные в России доклады про внутреннее устройство джавовых рантаймов. Конечно, JVM-инженеров среди участников не много, их вообще очень немного. Такие доклады в первую очередь нужны для того, чтобы почувствовать «сродство с машиной», как говорят профессиональные автогонщики. Можно прочувствовать всю скрытую механику, научиться использовать её особенности, да и просто удовлетворить любопытство. В этой знаковой категории докладов, программе конференции никак нельзя ударить в грязь лицом, и у неё явно получается. Эти доклады ведут самые известные в сообществе люди, представители разных рантаймов и компаний:
Здесь не перечислить всех, поскольку нет задачи скопировать программу с сайта, а только передать суть происходящего. Давайте взглянем только на парочку докладов.
Помните доклад о том, как написать GC за 20 минут (основанный на статье Шипилёва)? Charlie Gracie расскажет нам ещё более сакральную штуку — как написать свой JIT-компилятор за час. Конечно же, не обойдётся без проверенных решений вроде OMR, над которыми трудится Чарли.
Но часто ли вам действительно нужно писать свой JIT или GC? Андрей Паньгин расскажет про очередной важный способ работы с OpenJDK: работу с JVM Tool Interface — стандартный API для разработки всевозможных инструментов: профайлеров, отладчиков и диагностических утилит. Это нечто более существенное, легко представить, где это понадобится в ежедневной работе. Многие знают, что он полезен для написания Java-агентов, но он годится и для многого другого. На докладе будут разбираться способы работы с ним, баги, фичи, инсайты. Если же всё-таки хочется услышать про Java-агенты, про них поведает Rafael Winterhalter.
Enterprise
Тут критик воскликнет: «Да и Java-агенты я пишу, мягко говоря, не каждый день. Никогда не пишу!» О да, и поэтому все остальные категории докладов делают упор на применимость в различных направлениях разработки и архитектуры. Начнём, пожалуй, с самой очевидной категории — с кровавого энтерпрайза. В этой секции есть не только зарубежные звёзды вроде Sebastian Daschner (гуру JavaEE из IBM) и Milen Dyankov (евангелист Liferay), но и ведущие российские разработчики — Юрий Артамонов из Haulmont (CUBA, восемь лет с Vaadin), Григорий Кошелев из Контура, Владимир Плизга Toparvion из ЦФТ и так далее.
Я в первую очередь схожу на доклад Себастиана. Формально он Lead Java Developer Advocate в IBM, ответственный, кроме всего прочего, за стандарты JAX-RS и JSON-P и кучу опенсорсных проектов. Мы совсем недавно сделали с ним интервью для Хабра, которое скоро опубликуем. Совершенно очевидно, что если тема JavaEE и JakartaEE вообще хоть как-то интересует, то это ваш человек. Наибольшую ценность может принести общение в дискуссионной зоне, потому что Себастиан варится в JavaEE-мире, и к нему можно подходить с очень таргетированными вопросами, обсуждать и договариваться о конкретных вещах. Главное, не забудьте, что говорит он по-английски. В прошлый раз я выписал все интересующие меня вопросы на бумажку и нудно зачитывал по списку (не сказать, что так делать надо, но это работает):-)
Вы, наверное, привыкли, что про Spring рассказывают Толкачёв tolkkv и Борисов EvgenyBorisov. В этот раз у них немного другая штука, а обязательную тему Spring раскрывают Владимир Плизга из ЦФТ и Victor Rentea (техлид в IBM). У Виктора намечается длинная сессия лайв-кодинга, прерывающаяся на рассмотрение глубоких теоретических вопросов, а теория там потребуется — ибо это ваша любимая тема написания всевозможных прокси на Spring.
Reactive
Можно напрячься и вспомнить времена, когда реактивщина была разделом архитектурной астронавтики. Сейчас же эта тема прёт неостановимым паровозом: так получилось, что на этом JPoint докладов реактивной тематики больше всего! Например, их в два раза больше, чем докладов по «чистому» энтерпрайзу. И знаете, всё какие-то знакомые имена. Давайте пройдёмся по парочке докладов.
Кирилл Толкачёв и Евгений Борисов постараются разобраться, что из современных технологий всего лишь модные игрушки, а что — дельная вещь. Они возьмут какое-то приложение и попробуют отрефакторить его в реактивном стиле, раскрывая особенности вещей вроде Spring Web Reactive Framework. Звучит очень просто и незамысловато, но как мы знаем, их доклады — одни из лучших по рейтингам, посещаемости и проработке. Рекомендую взглянуть на предыдущий мегадоклад «Boot yourself, Spring is coming» (в двух частях: раз, два) — один из немногих, ради которого было зарезервировано два часовых слота подряд. По ссылкам есть как видео, так и текстовая расшифровка, но я настоятельно советую смотреть видео, потому что способ изложения имеет значение.
Давайте теперь немного о будущем, стремительно превращающемся в настоящее. Есть такая штука, RSocket — симметричный бинарный протокол поверх байтовых транспортов вроде TCP или вебсокетов, наконец-то позволяющий работать асинхронно. Он ещё не релизнулся до конца, но ждать недолго, да и открывающиеся перспективы широки. И на JPoint у нас есть специальный человек, Олег Докука c докладом по RSocket — коммиттер Reactor 3, автор книги «Reactive Programming with Spring 5», а теперь ещё и коммиттер RSocket. Если вам страсть как хочется работать на нормальных протоколах, но вначале нужно разобраться в теме и плотно пообщаться с создателями технологии, то вам нужен Олег.
Languages
Давайте нырнём назад к более системным штукам. Две следующие категории — языки и тулинг. У меня эта дихотомия на «физиков и лириков» ассоциируется с бесконечными священными войнами на Хабре и Реддите о том, что важней — иметь умный язык, который сам всё умеет, или IDE с искусственным интеллектом внутри, помогающую на каждом шагу. К счастью, у нас тут не Haskell и не Common Lisp: в Java-мире есть и умный язык, и отличные IDE, и мощные доклады по этому всему. С языковой стороны баррикады нас ждут два сотрудника JetBrains, технический директор Azul, функциональный программист из геймдева и даже живой Scala-подкастер из «Скалалаза» — Ольга Махасоева. В общем, отряд укомплектован чуть менее, чем полностью.
О будущем джавы мы слышали и читали неоднократно. Но тут особый случай — про миграцию на новые джавы будет говорить Саймон Риттер из Azul. Именно тот человек, который на такие речи имеет полное право. Рейнхольд, Гёц, Роуз… Риттер. Ну вы поняли. Сейчас Саймон представляет Azul в JCP Executive Committee и на экспертных группах по JSR 379 и JSR 383. В докладе он даст обзор широкого круга вопросов миграции: изменения в языке, библиотеках, настройках, и даже затронет эффекты от нашумевшего ускорения релизного цикла. Ещё один человек, с которым крайне рекомендую пообщаться в дискуссионной зоне — может быть, ваши вопросы окажут влияние на будущее Java.
Вторым докладом я бы сходил на «Kotlin/Native: why make a native language in 2019? What is beyond JVM?» Николая Иготти из JetBrains. Как известно, всё становится лучше, если это написано на Котлине 🙂 Тем не менее, нужность компилируемой в нативный код версии для многих всё ещё остаётся загадкой. Как минимум, компилируемых языков немало, а тут речь идёт ещё и о сравнительно молодом проекте. Не бойтесь, у нас тут не абы кто, а технологический руководитель проекта Kotlin/Native, он точно справится с любыми вопросами.
Tooling
Тулинг — штука тонкая. С одной стороны, каждый может про него что-то сказать, с другой — обычно такие разговоры, и даже целые доклады, сворачиваются в обычную вкусовщину или непонимание тонкостей разработки инструментов, которыми пользуешься не только ты лично, а ещё и половина мира. Такие компетенции есть обычно только у разработчиков соответствующего тулинга или евангелистов, тесно общающихся с пользователями этих инструментов. Наш «Tooling Team» на JPoint состоит из автора Jenkins, одного из разработчиков Gradle, главы берлинского JUG, и как повелось — двух сотрудников JetBrains.
Kohsuke Kawaguchi, технический директор CloudBees, — легендарная личность, он вот этими самыми руками сделал Jenkins и во многом определил уклад CI/CD технологий в России и мире. И конечно, он не будет рассказывать о каменных веках и далеко забытых багах. Речь пойдёт о совершенно новых и революционных вещах в Jenkins. Доклад прямо сейчас находится в проработке вместе с Программным комитетом, и в будущем название и план доклада, опубликованные на сайте JPoint, могут меняться.
Вторым докладом, конечно, стоит упомянуть Тагира Валеева lany — разработчика в JetBrains, изобретателя множества крутых штук, которыми все мы пользуемся, запустив IntelliJ IDEA. На этот раз будет доклад про атомарный рефакторинг, который рассматривает насущную проблему и боль: не сломается ли программа после автоматического рефакторинга? Тагир научит, каким образом можно заставить IntelliJ IDEA рефакторить атомарно, не ломая семантику, даже если она сопротивляется.
Вне категорий
А ещё у нас есть докладчик вне категорий — Егор Бугаенко yegor256, директор компании Zerocracy. Он написал как минимум две книги о правильном ООП (раз, два — там не очередное описание паттерна Singleton, а реально есть чего почитать), контрибьютит кучу кода в опенсорс и делает необычные провокационные доклады. Постоянные посетители наших конференций знают, что когда-то давно специально ради него изобрели маркер «Готовьтесь, будет подгорать». Сейчас этого маркера на докладе не стоит, а название «Просчеты тестирования» и описание доклада выглядят предельно серьезно и прагматично. Умеет ли Егор делать доклады, которые не взрывают аудиторию? Посмотрим.
Тренинг «Pragmatic Design Patterns with Spring», ведущий — Victor Rentea
Как вы уже могли заметить, в программе конференции есть доклад про прокси на Spring, который представляет из себя сессию лайвкодинга. Но это ещё не всё.
За один день до начала JPoint, то есть 4 апреля, Виктор собирается провести большой 8-часовой тренинг, посвященный дизайну чистого, хорошо спроектированного кода (в том числе тому, как отрефакторить свой легаси до такого состояния).
Обучаться предстоит примерно следующему:
Участнику тренинга лучше заранее ознакомиться со Spring, если он этого ещё почему-то не сделал, и вообще уметь программировать на Java.
За подробной информацией о тренинге стоит обратиться на сайт JPoint.
FAQ: и всё, только доклады?
Конечно, конференция — это не только доклады, но и море общения. Этим живое присутствие отличается от онлайн-трансляции, которую мы тоже планируем сделать.
Поглядите на список выше — с большей частью этих людей хотелось бы встретиться и обсудить что-то важное. Такая возможность у нас есть: после окончания доклада все направляются в дискуссионную зону и общаются там столько, на сколько хватит времени. В конце дня организуются так называемые BOF-сессии (что-то вроде круглого стола, но только участвуют все).
Можно просто встретиться с интересными людьми из сообщества, которые тоже пришли, но без доклада. Можно найти интересующие компании, что-нибудь узнать у их представителей и поучаствовать в конкурсах. Будут разные побочные активности, которые мы сейчас продумываем. Словом, всё что можно представить о большой конференции.
Что дальше?
А дальше нужно приходить на JPoint! Он пройдёт 5-6 апреля 2019 в Москве.
Билеты можно приобрести на официальном сайте. Там же можно подробно ознакомиться с текущей версией программы (она может немного изменяться, и об изменениях мы зачастую пишем на Хабре).
Важное замечание про цены и скидки. По сравнению с предыдущим JPoint, система покупки билетов стала гибче и теперь умеет выдавать билеты четырех типов: Academic, Personal, Standard и Online. Почему это важно: если вы покупаете билеты себе сами, то это будет стоить сильно дешевле, чем билет для компании. А если вы студент, аспирант или преподаватель (и имеется соответствующий документ для подтверждения), то скидка получается особенно внушительной. Подробные условия, конечно, нужно читать на сайте — всё вышенаписанное было только для ознакомления.
В ожидании JPoint 2019 можно посмотреть записи с конференций за прошлые годы. Они аккуратно лежат на нашем YouTube-канале. Прошлогодние записи выкладываются туда перед началом новой конференции, и таким образом вы можете наглядно оценить качество докладов.
Разбираемся с Custom Tooling в Argo CD
Спустя некоторое время после написания первой статьи, где я ловко управлялся с jsonnet и гитлабом, я понял что пайплайны это конечно хорошо, но излишне сложно и неудобно.
В большинстве случаев требуется типовая задача: «сгенерировать YAML и положить его в Kubernetes». Собственно, с чем Argo CD замечательно и справляется.
Большинству пользователей этого набора будет достаточно, но не всем. Для того чтобы удовлетворить потребности всех и каждого в Argo CD имеется возможность использовать custom tooling.
В первую очередь интересует возможность добавления поддержки qbec и git-crypt, которые с полна были рассмотренны в предыдущей статье.
Прежде чем приступить к конфигурации, нужно сначала разобраться с тем как именно Argo CD работает.
Для каждого добавленного приложения он имеет две фазы:
Примечательно то, что Argo применяет этот подход для любого типа приложений, в том числе и для Helm. То есть в Argo CD Helm не занимается деплоем релизов в кластер, а используется только для генерации манифестов.
Со своей стороны Argo умеет нативно обрабатывать Helm-хуки, что позволяет не нарушать логики применения релизов.
Qbec позволяет удобно описывать приложения с помощью jsonnet, а кроме того имеет возможность рендерить Helm-чарты, а так как Argo CD умеет нормально обрабатывать Helm-хуки, то использование этой возможности с Argo CD позволяет добиться ещё больее корректных результатов.
Для того чтобы добавить поддержку qbec в argocd нужно две вещи:
Первая задача решается довольно просто:
*(команда init не используется)`
Для добавления бинарников предлагается собрать новый образ, или использовать трюк с init-контейнером:
Теперь посмотрим как будет выглядеть манифест нашего приложения:
В переменной ENVIRONMENT мы передаём имя окружения для которого нужно выполнять генерацию манифестов.
применим и посмотрим что у нас получилось:
приложение задеплоилось, отлично!
git-crypt
Git-crypt позволяет настроить прозрачное шифрование репозитория. Это простой и безопасный способ хранить конфиденциальные данные прямо в git.
С имплементацией git-crypt оказалось сложнее.
Теоретически мы могли бы выполнять git-crypt unlock на init-стадии нашего custom-плагина, но это не очень удобно, так как не позволило бы использовать нативные методы деплоя. Например в случае Helm и Jsonnet, мы теряем гибкий GUI-интерфейс который позволяет упростить настройку приложения (values-файлы и прочее).
Именно по этому хотелось выполнять распечатывание репозитория еще на более ранней стадии, при клонировании.
Так как на данный момент Argo CD не предоставляет возможности для описания каких-либо хуков для синхронизации репозитория, пришлось обойти это ограничение хитрым шелл скриптом-обёрткой, который заменяет собой команду git:
Argo CD выполняет git fetch каждый раз перед операцией деплоя. Именно на эту команду мы и повесим выполнение git-crypt unlock для разблокировки репозитория.
для тестов можете использовать мой docker-образ в котором уже есть всё необходимое:
Теперь нам нужно подумать о том, как Argo будет расшифровывать наши репозитории. А именно сгенерировать gpg-ключ для него:
Сохраним имя ключа 8CB8B24F50B4797D для дальнейших шагов. Экспортируем сам ключ:
И добавим его в виде отдельного секрета:
Единственное что нам осталось, это пробросить его в контейнер argocd-repo-server, для этого отредактируем deployment:
Argo CD автоматически подгружает gpg-ключи из этой директории при старте контейнера, таким образом он загрузит и наш приватный ключ.
Отлично, ключ загружен! Теперь нам достаточно добавить Argo CD в наш репозиторий в качестве коллаборатора и он сможет автоматически расшифровывать его на лету.
Импортируем ключ на локальный компьютер:
Настроим уровень доверия:
Добавим argo в качестве коллаборатора в наш проект:
Ссылки по теме:
Гайд для развития фронтенд-разработчика в 2021
Об этом гайде
Этот FAQ посвящен введению во фронтенд-разработку. Данное вступление было составлено со слов уже опытных разработчиков для начинающих. Прежде, чем задать вопрос — прочитайте его полностью. Основное предназначение FAQ’a — дать краткое, но емкое направление по оптимальному изучению стека технологий, которые используются во фронтенде.
Интро
Фронтенд в 2020+ — это не:
B 2021 фронтенд-разработка — это создание веб-приложений на JS’e. Хотя верстка отошла на второй план, это не значит, что изучать ее не обязательно — браузеры все так же понимают только CSS-стили, поэтому вы обязательно столкнетесь с ними на работе.
Что нужно знать на позицию фронтенд-разработчика начально-среднего уровня:
Попутно изучается работа с командной строкой, git, инструменты сборки и прочие штуки. Все теоретические навыки обязательно подкрепляются практикой.
FAQ не освещает вопросы уровня:
Можете, но это вряд ли будет эффективно.
Мы тоже такое слышали, но обычно под «портфолио» понимают профиль на гитхабе и ссылочки на завершенные/активные проекты (если позволяет NDA | заказчик). В принципе, если не лень — можно даже простенький сайтецкий о себе забацать.
Через конструктор можно создать лендинг с рекламой ноготочков, что-то сложнее – нет.
Можно посмотреть гарвардский курс CS50. На ютубе есть его русскоязычная версия от 2015 года (с тех пор ничего не поменялось). Англоязычную версию можно найти посвежее. Это необязательно, но будет полезно.
Верстка
Основы
Что нужно знать
Итого
Умение сверстать простенькую статику, без новомодных фич, без семантики, модульности, бэмов, респонсивности и прочего. На все про все около месяца.
Где учить, что читать
Не стоит увлекаться просмотром сотен тысяч курсов, вебинаров, туториалов и прочему. Как правило хтмл академии + хтмлбука более чем достаточно для усвоения азов верстки.
Очень подробный верстка-гайдлайн
Стоит как минимум бегло просмотреть и прикинуть, что к чему: http://webmasters.teamdev.com/
Верстка advanced
Что нужно знать
На все про все: еще месяц-два-три в худшем случае.
Итого получаем
Готовую личинку верстальщика, которая сможет заверстать статику любой сложности по данному макету. Теоретически можно работать за дошираки (спойлер — на самом деле нельзя)
Где учить, что читать
Дополнительные ресурсы, которые могут быть полезными на данном этапе:
А книги, книги то будут? Хочу книжку!
Книги надо выбирать индивидуально. Если по HTML/CSS, то желательно, чтобы книга была не старше 2012 года, ну или хотя бы переиздана. Читай все что интересно. В любом случае это будет полезно.
Что верстать
В чем работать
На двнный момент VSCode – это дефолтный редактор для фронтендеров и не только. Вся суть в гибкой настройке, ультраполезных плагинах и регулярных обновлениях. После перехода на жс+фреймворки в нем можно будет продолжать полноценно работать. Те, у кого дрова вместо рабочей станции, могут попробовать Sublime или NP++, но со временем с них все равно придется слезать.
Что делать дальше
Сверстать пару макетов для закрепления и переходить к JS. Не помешает сразу зацепить гит, основные команды в терминале, поколупать какую-нибудь бубунту на виртуалке. Само собой использование сборщика, отсутствие боязни терминала, понимание того, как браузер рендерит страничку, как лучше подключать шрифты/стили/скрипты и т.п.
Гайд от анона по гитхабу
Еще один неплохой гайд по гитхабу (на русском)
JavaScript
Мир верстки был довольно дружелюбным и понятным. Мир JS — это особый мир особого программирования, где любая задача может иметь десятки решений, где существуют сотни и тысячи инструментов, библиотек и подводных камней. Добро пожаловать в ад.
Шутка. На самом деле, все довольно хорошо, и есть устоявшийся мейнстримовый набор:
Помните, что ньюфага никто (адекватный) не посадит, например, писать / править конфиги под SSR, поэтому учить наизуть webpack internals нинужно.
Обновляемый роадмап frontend-разработчика. Не стоит пугаться большого разнообразия – основное, это то, что отмечено фиолетовым. Дойдя до react/redux уже можно искать работу.
Основы
Английская версия поддерживается автором в более актуальном состоянии. Сразу дается ES6, убрано всякое говно мамонта, пугающее ньюфагов.
Кантора нужно разнообразить видосами и другими сайтами. Одна и та же вещь, объясненная много раз разными словами, становится понятнее:
Продолжение
А… книжки?
Само собой. Ниже представлены только материалы со свободным лицензированием (бесплатные), их более, чем достаточно. Раздел давно не обновлялся, но почти все актуально до сих пор, и будет актуально еще долго. И да, почти все на английском, увы и ах.
Функциональный / асинхронный JS
А как же регулярные выражения?
Не волнуйтесь, мы про них не забыли. Об этом и пойдет речь в данном разделе.
Для тех, кто не знает, что это такое и для чего нужно, объясню более подробно. После чего предоставлю полезные ссылки на различные материлы по данной тематике.
RegExp или, так называемые, регулярки — это наборы символов, применяемых для поиска текстовых строк, соответствующих требуемым условиям. Результат применения регулярного выражения — подмножество данных, отобранное согласно логике, заложенной в выражении. Они применяются в любых задачах по поиску в множестве данных, для которых нужно получать выжимку по определенным правилам.
Хм, а как же найти этот RegExp в коде? Как он выглядит?
Как я и обещал, список полезных ссылок по регулярным выражениям:
Что уметь?
Писать рабочий, хорошо структурированный, модульный код ОБЯЗАТЕЛЬНО на ES6 (лучше всего сразу привыкать к TypeScript). Для практики стоит придумать задачу — неважно, насколько шаблонной / скучной / избитой она будет. Легендарный тудулист вполне подойдет для оттачивания навыков: здесь вам и события, и работа с ДОМ, и обработка форм, можно прикрутить хранилище данных (localStorage, firebase) или даже «полноценный» бэкенд. К тому же, кода вполне достаточно для того, чтобы, например, написать приложение, используя MVC.
Мой друг Самуил-Реактовец сказал, что прототипы не нужны. Можно их пропустить, уж очень они мудреные? Есть же ES6!
Нельзя. Во-первых, это один из самых часто встречающихся вопросов на собеседовании. Во-вторых, это основа основ JS, прототипы были, есть, будут и никуда не денутся, никакие ES6 классы и готовые либы этого не изменят. Понять прототипы === понять, как работает все, что на них завязано. А на них завязано вообще все. Ну, почти.
Все теоретические навыки обязательно подкрепляются практикой. Решайте задачки Кантора, каты на CodeWars, задачи из разделов «Basic/Intermediate Algorithm Scripting» на freecodecamp. Попробуйте написать что-нибудь несложное, пусть код будет похож на императивную простыню: главное, чтобы работало.
Advanced
Промышленное программирование
Пришло время преодолеть разрыв между легкими и приятными учебными заданиями и суровой практикой с которой вам предстоит столкнуться на работе.
Выбор фреймворка
Первое и единственное решение, которое нужно принять: на какой фреймворк садиться. На текущий момент (2020) на выбор 2 с половиной стула:
Первый стул — React
Традиционный выбор редакции (upd: в 2021 Реакт по прежнему универсальный выбор, замена не предвидится). Ньюфажикам его советуют по многим причинам:
Но Реакт не фреймворк, мне так на курсах сказали!
Есть строгий критерий, определяющий грань между фреймворком и кастомым кодом/библиотекой. Для тех, кому впадлу читать — Реакт вполне себе фреймворк. Свои недовольства можете отправлять в спортлото.
Второй стул — Vue 2
Второй с половиной стул — Angular
Трудное дитя гугла, поимело провальный старт, из-за чего его считают плохим, негодным, что, на самом деле, не так.
Это были стулья, а теперь табуретки:
Вышеперечисленные штуки указаны сугубо в ознакомительных целях.
Т.к. ваши покорные слуги — потомственные реактогоспода, то направление по изучению фреймворка дается именно на примере реакта, но вполне подойдет и для вью, и для ангулара. Лучшие ресурсы для начала обучения — официальная документация. Что у Реакта, что у Ангулара, что у Вью она очень подробная и человеческая.
Релейтед ресурсы:
Список из годных, просмотренных очень многими анонами ютуб-каналов и курсов:
Кривая обучения в этом месте резко становится очень крутой и преодолеть ее с первого раза получается не у всех. Документация, случайные статьи и твиттеры разработчиков станут вашими новыми друзьями. И, конечно, эксперименты и практика.
Сборка
Тут следует сказать, что для учебных и личных проектов в 90% случаев будет хватать Create React App или другого бойлерплейта. В таком случае webpack и babel уже зарание настроены во внутренностях и его можно не трогать. На промышленных проектах возможностей бойлерплейта обычно не хватает, поэтому рано или поздно вы столкнетесь с настройкой этих тулзов. Но еще раз – ньюфага никто не посадит править сложный конфиг на большом проекте, поэтому без фанатизма.
Деплой
Чтобы ваши проектики увидел будущий работодатель, их нужно задеплоить – то есть развернуть где-то на сервере в продакш–режиме. Сейчас сделать это стало очень просто, есть несколько вариантов:
Деплоим, ссылки указываем резюме, работодатель тыкает (но это не точно) наши проекты, убеждается в нашей крутости, profit.
Что делать дальше
Если вы уже состояфшийся фронт и вам кажется, что развиваться больше некуда — вынуждены вас разочаровать.
TL;DR: В 2020 TypeScript стал стандартом, большинство новых проектов стартуют на нем. Все остальное (кроме кофе) можно потрогать на досуге, но в основном для саморазвития – работы на этом очень мало. Кофе не нужно, пейте чай. Шутка. Нет, правда, кофескрипт не нужен.
Выбрав стул с реактом, можно смотреть в сторону таких вещей:
Независимо от стула:
Не забываем про линтинг ESLint который избавит от совсем уж тупых ошибок/опечаток и приучит к написанию красивого кода.
Навыки работы с консолью и гитом подразумеваются для любого разработчика по умолчанию, об этом часто даже не пишут в вакансии.
Лицензии
Для чего нужны лицензии, какую лучше применить для того или иного проекта, что они разрешают, а что нет — знать нужно. Поэтому предоставляю ссылку на замечательный ресурс TLDRLegal, который поможет разобраться во всем этом.
Устройство на работу
Причесываем гитхаб, маскируем коммиты уровня «ффыарфрырыффф». Составляем адекватное резюме, рассылаем его по всему хедхантеру, небо и Аллаха в копию. Впрочем, если в резюме видны зачатки мысли (и вы в ДС), то HR скоро вас сами найдут и обрушат лавину звонков и писем.
Основная часть собеседования это рассказ о себе и своих проектах. Заранее подумайте что сказать. Если есть ноутбук, то приходите с ним и показывайте проекты вживую.
Если ты живешь в мухосранске, то хорошим вариантом зарабатывать 900кк/наносек может быть удаленка. Уточним – под удаленном работой понимается не фриланс, а все та же работа в компании/студии, только с дому. Спасибо пандемии – количество удаленных вакансий возросло многократно, после пандемии возможно многие так и не вернутся в офисы. Вот где можно найти нормальные (и дерьмовые) вакансии на удаленочку:
Платиновые вопросы на собеседованиях
Большая часть из них разобрана здесь: Вопросы кандидату на должность front-end разработчика. Можно посмотреть «Собеседования в прямом эфире» на канале хекслета.
Дополнительно
Английский
Нужен ли английский и как его выучить? Я и так уже по самую макушку завален материалами!
Нужен. Большая часть самых клевых материалов — на английском, большая часть влиятельных / шарящих людей в коммьюнити — не из СНГ и общаются на английском или своем родном (передаю привет одному голландцу). Плюс это нехилый бонус к трудоустройству.
Ниже будет подборка ответов / материалов по англйискому от анонов, за что им спасибо.
Как учить?
Практикой и погружением:
Для грамматики подойдет курс от Полиглот 16 уроков. Еще стоит отметить простой переводчик по клику для хрома LinguaLeo. Другое полезное расширение — Grammarly, смотрит за правильностью того как ты пишешь на английском и высвечивает ошибки, неправильную грамматику, подсказывает правильный порядок слов и так далее. А ещё он может показывать значение слова по клику, с полноценной выдачей о значении этого слова.
Читать поначалу можно словарём — Chrome, Google Dictionary дополнение. Кликанье на все непонятные слова во время чтения/раздумья над смыслом статьи должно стать привычкой.
Обычно сначала трудно но через пару недель чувствуешь результат, потом уже стабильное улучшение.
Подкасты
Подкасты сейчас очень популярны, только ленивый их не записывает. Но среди всей этой кучи встречаются реально интересные, где можно послушать крутых спецов из той или иной сферы или что-то полезное узнать. По фронтенду их существует огромное количество как на русском языке, так и на английском (в этом случае можно прокачать свой скилл восприятия английского на слух). Вот самые популярные из них.
Большинство людей любят игры. Но как же приятно осознавать, что ты проводишь время с пользой, играя в них. Ниже приведу список игр, нацеленных на прокачку различных технологий и работй с алгоритмами:
Прочие мелочи
Правда ли, что JS был придуман за 10 дней? Мой друг Вася-Джавист сказал, что это ущербный недоязык, хах.
Первая спецификация действительно была разработана и утверждена в кратчайшие сроки, и предназначалась для решения примитивнейших задач (оживить картинку, подсветить кнопочки). С тех пор прошло очень много времени, от первой спецификации осталась только общая концепция да парочка досадных багов, которые нельзя пофиксить из-за обратной совместимости (typeof Null, ага).
Нужен ли матан?
Скажем так: лишним не будет, но и без него frontend разработчик не чувствует себя ущербным. Полезными будут знания дискретной математики, теории чисел и графов, а также основы теории алгоритмов (впрочем, это уже CS). Все это вполне изучается самостоятельно в свободное время. Для практики в этом деле лучше использовать Python: он более строгий, лаконичный и понятный. Хотя и на ES6 получаются очень даже красивые решения всяких олимпиадных задачек.
Хочу фрилансить!
Фрилансить версталой — гиблое дело. Да и вообще фрилансить без опыта работы — гиблое дело. Да и вообще фрилансить в 2017 — гиблое дело. Адская конкуренция, кривые ТЗ, неадекватные заказчики, баны на апворках и прочие прелести ждут. Но никто не мешает попробовать.