Всем привет, в голосовании за время проведения стрима с версткой большинство проголосовало за вечер 25 мая. Но так случилось, что я в этот день никак не смогу провести стрим.
Что скажете, если мы перенесем стрим 1 июня так же в 18:00 по МСК?
Ставьте 👍🏻 если придете и 👎🏻 если хотите быть на стриме, но нужно выбрать другой день и время.
Что скажете, если мы перенесем стрим 1 июня так же в 18:00 по МСК?
Ставьте 👍🏻 если придете и 👎🏻 если хотите быть на стриме, но нужно выбрать другой день и время.
👍4
Ну что, через пол часика запускаю стримец, ссылочку пришлю сюда) Кого ждать?)
Поверстать не поверсталось, зато приятно было поболтать. В следующий раз точно получится)
🔥2😁1
Всем привет)
Пишу сказать, что нет — канал не заброшен, просто разные события закрутили меня, а жара добила😅 В скором времени хочу сделать вторую трансляцию и все же поверстать выбранный нами макет. И еще готовлю пару постов про практикум и не только.
Спасибо, что остаетесь со мной❤️
Пишу сказать, что нет — канал не заброшен, просто разные события закрутили меня, а жара добила😅 В скором времени хочу сделать вторую трансляцию и все же поверстать выбранный нами макет. И еще готовлю пару постов про практикум и не только.
Спасибо, что остаетесь со мной❤️
👍2
Приступила к подготовке новых постов, поскольку стало посвободнее дышать.
А пока вот что хотела вам напомнить. Делать что-то в первый раз или даже разы всегда сложно.
На днях увидела красивые сережки из бисера и захотелось мне сделать такие же. Инструкция есть, бисер купила, что еще надо. Но первые 5 попыток понять, как это все нужно делать окончились полным провалом. 5 раз мне хотелось бросить эту затею, начала болеть спина, руки не слушались, а схемы казались бесполезными.
Сплела все-таки, да самый простой узор, да выглядит наивно и ни разу не то, что я хотела изначально. НО делать что-то впервые всегда сложно, будь то рукоделие или задача с которой вы никогда раньше не сталкивались. Эффект один и причины одни и те же. В нашем мозгу пока нет связей, которые отвечают за решение новых задач. Создавать новые нейронные связи больно и тяжело, но если они создадутся, мы поумнеем)
Короче, мораль сей басни такова: не бросайте в порыве разочарования, просто пробуйте еще. Если вам интересно или нужно сделать, связь между нейронами вырастет и все получится
А пока вот что хотела вам напомнить. Делать что-то в первый раз или даже разы всегда сложно.
На днях увидела красивые сережки из бисера и захотелось мне сделать такие же. Инструкция есть, бисер купила, что еще надо. Но первые 5 попыток понять, как это все нужно делать окончились полным провалом. 5 раз мне хотелось бросить эту затею, начала болеть спина, руки не слушались, а схемы казались бесполезными.
Сплела все-таки, да самый простой узор, да выглядит наивно и ни разу не то, что я хотела изначально. НО делать что-то впервые всегда сложно, будь то рукоделие или задача с которой вы никогда раньше не сталкивались. Эффект один и причины одни и те же. В нашем мозгу пока нет связей, которые отвечают за решение новых задач. Создавать новые нейронные связи больно и тяжело, но если они создадутся, мы поумнеем)
Короче, мораль сей басни такова: не бросайте в порыве разочарования, просто пробуйте еще. Если вам интересно или нужно сделать, связь между нейронами вырастет и все получится
❤2💯2❤🔥1
А что касается новых постов. За такой пробел без них, предлагаю выбрать и тех что подготовленный или почти, о чем интереснее будет почитать (в итоге будут все)
Anonymous Poll
43%
Перечень необходимые знания TS (на мой взгляд)
29%
Необходимые знания JS (на мой взгляд)
14%
Про семантическую верстку и валидацию HTML
14%
Селекторы и их комбинации. Преоритеты, веса.
Так-с, перечни, ожидаемо, стали самыми популярными, ближе к выходным будет пост, надо отредактировать текстик)
👍2❤🔥1
Что необходимо знать JS (осторожно! субъективное мнение)
Самое главное, JS — это хлеб насущный для фронта.
Ха-ха.
В браузере интерпретируется только он — JavaScript.
TypeScript транспилируется в JS.
В основе фреймворков и библиотек лежит JS.
Так что постигать искусство владения JS придется.
Напомню, что JS не компилируемый, а интерпретируемый. Это значит, что он сразу как есть, ну почти, исполняется браузером. А значит реализация языка напрямую зависит от среды исполнения кода.
В связи с этим, ряд особенностей JS, такие, как hoisting, кажутся устаревшим рудиментом, что на первый взгляд справедливо, ведь теперь никто не использует var, а let и const ограниченны блоком кода. Однако, его наличие, как ни странно, продиктовано особенностями работы браузеров. Поэтому считать его рудиментом не верно.
Короче говоря, у всего странного в JSпочти есть смысл и причина.
1. Понимая, как работает и выполняется JS будет проще найти ошибку или понять почему одно решение задачи вам подойдет лучше другого.
2. Если не пропускать такие моменты, как с хоистингом из-за бессмысленности, а понять, почему они существуют и в каком процессе браузера участвуют, вам будет проще их запомнить, переварить и принять. А значит время подготовки к каждому собесу сильно сократиться. Теперь же не надо заучивать.
3. Ну и опять же, фреймворки и библиотеки не работают на магии. Они работают на использовании того, что есть и встроено в JS, который зависит от среды в доме который построил Джек
Кстати, если вы уже приготовились парировать про зависимость JS от процессов браузера, что: «ваще-т есть JS для бэкенда» — то я вас расстроюили нет, там есть своя среда выполнения, которая имеет схожие особенности исполнения кода.
Если вы ждете прямо список, что учить, чтобы знать JS, то открывайте learn.javanoscript и вперед.
Разочарованы? Штош, иначе никак, это самый хороший источник для начинающих на мой взгляд, чтобы кто не думал про него. Там простым языком, периодически схематически, объясняется БАЗА.
Но для вас у меня есть кое-что. Не гайд и не список для подготовки к собеседованию. И да, это список не привязанный к ГРЕЙДу. Это то, к пониманию и знанию чего нужно прийти. Дальше, вы уже и сами будете ориентироваться, куда копнуть и что еще изучить. Этот список я бы хотела получить лет 6-7 назад)
Самое главное, JS — это хлеб насущный для фронта.
«Да никто не пишет на чистом JS.»
«Я лучше сразу научусь писать на React/Vue.»
«Во всех вакансиях вижу не JS, а TS».
Ха-ха.
В браузере интерпретируется только он — JavaScript.
TypeScript транспилируется в JS.
В основе фреймворков и библиотек лежит JS.
Так что постигать искусство владения JS придется.
Напомню, что JS не компилируемый, а интерпретируемый. Это значит, что он сразу как есть, ну почти, исполняется браузером. А значит реализация языка напрямую зависит от среды исполнения кода.
В связи с этим, ряд особенностей JS, такие, как hoisting, кажутся устаревшим рудиментом, что на первый взгляд справедливо, ведь теперь никто не использует var, а let и const ограниченны блоком кода. Однако, его наличие, как ни странно, продиктовано особенностями работы браузеров. Поэтому считать его рудиментом не верно.
Короче говоря, у всего странного в JS
1. Понимая, как работает и выполняется JS будет проще найти ошибку или понять почему одно решение задачи вам подойдет лучше другого.
2. Если не пропускать такие моменты, как с хоистингом из-за бессмысленности, а понять, почему они существуют и в каком процессе браузера участвуют, вам будет проще их запомнить, переварить и принять. А значит время подготовки к каждому собесу сильно сократиться. Теперь же не надо заучивать.
3. Ну и опять же, фреймворки и библиотеки не работают на магии. Они работают на использовании того, что есть и встроено в JS, который зависит от среды в доме который построил Джек
Кстати, если вы уже приготовились парировать про зависимость JS от процессов браузера, что: «ваще-т есть JS для бэкенда» — то я вас расстрою
Если вы ждете прямо список, что учить, чтобы знать JS, то открывайте learn.javanoscript и вперед.
Разочарованы? Штош, иначе никак, это самый хороший источник для начинающих на мой взгляд, чтобы кто не думал про него. Там простым языком, периодически схематически, объясняется БАЗА.
Но для вас у меня есть кое-что. Не гайд и не список для подготовки к собеседованию. И да, это список не привязанный к ГРЕЙДу. Это то, к пониманию и знанию чего нужно прийти. Дальше, вы уже и сами будете ориентироваться, куда копнуть и что еще изучить. Этот список я бы хотела получить лет 6-7 назад)
👍1
Так что же необходимо знать в JS?
— Общая картина: Как работает? Где работает? Почему так произошло исторически? Не прочитать для галочки, а понять первопричины.
— EventLoop: Куда без него. Подробность знания может быть разного уровня, чем дальше вы будете погружаться в JS тем более четкое представление у вас появиться, но для начального этапа лучше схематично представлять путешествие исполняемого кода из вашего скрипта по нему. Отдельно про обожаемую мной тему я еще напишу потом. Вам не отвертеться.
— Разницу ссылочного и примитивных типов данных: Так будет поменьше сюрпризов и станет понятно, почему на собесах так докапываются до копирования и клонирования объектов.
— Конечно не обойтись без набора джентльмена: умение работать с массивами, объектами, условными операторами и операторами цикла — это Base.
— Типы переменных и особенности их приведения: Особенно стоит обратить внимание на принципиальную разницу null и undefined. В контексте рабочих задач это полезно понимать. Если вы еще и понимаете, почему ваш [ ] может превратиться в пустую строку — ваще умнички.
— Тот самый указатель контекста this. Его использование с функциями и объектами: На куда в какой момент указывает и что с этим делать. Так как язык интерпретируемый, браузеру просто необходимо понимать, что использовать в тот или иной момент и он использует указатель на контекст. А вам соответственно было бы не плохо понимать, на что браузер будет смотреть, чтобы ваш код работал более ожидаемо.
— Особенности стрелочных функций, тех самых, которые по началу могут пугать новичков. А почему? А потому что надо понимать, что такое callback. Спойлер, ничего страшного, коллбек — это просто функция, которая будет вызвана позже.
— Promise и прочая ассинхронщина: Promise — как много в этом слове. Не забывайте при изучении обращать больше внимания на его путешествие по EventLoop, до этого разберитесь для себя раз и навсегда что такое callback и будет вам счастье.
— Вызов функций при событиях на странице: Сейчас мало кто пишет на чистом JS, да и до фреймворков использовали jQuery. Однако стоит понимать, как мы можем писать скрипты и вызывать их по событию на каком-либо элементе разметки. (Открыть модалку по клику, добавить или удалить элемент списка. И все только с JS)
— Работа с конструкторами классов не менее важно, хотя бы потому что мы невольно используем встроенные конструкторы при использовании new Promise.
Еще лет 5 назад я бы точно написала, что наследование это супер важно, как и замыкание. Но тенденции немного изменились. Из «условно объектно-ориентированного» JS превратился в «функционально-ориентированный язык». И писать свои классы, наследовать и расширять их мы стали сильно меньше. Быть в курсе да, но до мелочей знать как этот механизм устроен на начальных этапах, пожалуй, я советовать не буду. Уверена, что найдутся люди, которые оспорят мое убеждение, и это прекрасно.
Так как в web-разработке фронтенд в вакууме редко существует, фронтендерам нужно уметь работать с API — прослойкой, позволяющей обмениваться данными с сервером. Практика наберется со временем, а чтобы поэкспериментировать с отправкой запросов, можно поискать отрытые API для обучения. Правда в них, скорее всего, будет доступен только метод GET, и соображений безопасности, конечно же.
* Минимум:
- методы запросов (GET, POST и т.д.),
- коды ответов (100, 200 и т.д),
- какие бывают заголовки запросов и как можно передать параметры запроса (через url или через body)
* Тут как раз самое частое применение ассинхронщины во всех ее проявлениях: async/awit, promise, setTimout, setInterval.
* Бонусом можно еще изучить разницу REST/REST full API, что там какие принципы как работают. Да, фронтендер вряд ли будет писать бэкенд, но осведомленность никогда не мешала (в моей практике как минимум)
* А если стало интересно разобраться, как например работают чаты, то webSocket и прочие радости тоже пригодятся.
— Общая картина: Как работает? Где работает? Почему так произошло исторически? Не прочитать для галочки, а понять первопричины.
— EventLoop: Куда без него. Подробность знания может быть разного уровня, чем дальше вы будете погружаться в JS тем более четкое представление у вас появиться, но для начального этапа лучше схематично представлять путешествие исполняемого кода из вашего скрипта по нему. Отдельно про обожаемую мной тему я еще напишу потом. Вам не отвертеться.
— Разницу ссылочного и примитивных типов данных: Так будет поменьше сюрпризов и станет понятно, почему на собесах так докапываются до копирования и клонирования объектов.
— Конечно не обойтись без набора джентльмена: умение работать с массивами, объектами, условными операторами и операторами цикла — это Base.
— Типы переменных и особенности их приведения: Особенно стоит обратить внимание на принципиальную разницу null и undefined. В контексте рабочих задач это полезно понимать. Если вы еще и понимаете, почему ваш [ ] может превратиться в пустую строку — ваще умнички.
— Тот самый указатель контекста this. Его использование с функциями и объектами: На куда в какой момент указывает и что с этим делать. Так как язык интерпретируемый, браузеру просто необходимо понимать, что использовать в тот или иной момент и он использует указатель на контекст. А вам соответственно было бы не плохо понимать, на что браузер будет смотреть, чтобы ваш код работал более ожидаемо.
— Особенности стрелочных функций, тех самых, которые по началу могут пугать новичков. А почему? А потому что надо понимать, что такое callback. Спойлер, ничего страшного, коллбек — это просто функция, которая будет вызвана позже.
— Promise и прочая ассинхронщина: Promise — как много в этом слове. Не забывайте при изучении обращать больше внимания на его путешествие по EventLoop, до этого разберитесь для себя раз и навсегда что такое callback и будет вам счастье.
— Вызов функций при событиях на странице: Сейчас мало кто пишет на чистом JS, да и до фреймворков использовали jQuery. Однако стоит понимать, как мы можем писать скрипты и вызывать их по событию на каком-либо элементе разметки. (Открыть модалку по клику, добавить или удалить элемент списка. И все только с JS)
— Работа с конструкторами классов не менее важно, хотя бы потому что мы невольно используем встроенные конструкторы при использовании new Promise.
Еще лет 5 назад я бы точно написала, что наследование это супер важно, как и замыкание. Но тенденции немного изменились. Из «условно объектно-ориентированного» JS превратился в «функционально-ориентированный язык». И писать свои классы, наследовать и расширять их мы стали сильно меньше. Быть в курсе да, но до мелочей знать как этот механизм устроен на начальных этапах, пожалуй, я советовать не буду. Уверена, что найдутся люди, которые оспорят мое убеждение, и это прекрасно.
Так как в web-разработке фронтенд в вакууме редко существует, фронтендерам нужно уметь работать с API — прослойкой, позволяющей обмениваться данными с сервером. Практика наберется со временем, а чтобы поэкспериментировать с отправкой запросов, можно поискать отрытые API для обучения. Правда в них, скорее всего, будет доступен только метод GET, и соображений безопасности, конечно же.
* Минимум:
- методы запросов (GET, POST и т.д.),
- коды ответов (100, 200 и т.д),
- какие бывают заголовки запросов и как можно передать параметры запроса (через url или через body)
* Тут как раз самое частое применение ассинхронщины во всех ее проявлениях: async/awit, promise, setTimout, setInterval.
* Бонусом можно еще изучить разницу REST/REST full API, что там какие принципы как работают. Да, фронтендер вряд ли будет писать бэкенд, но осведомленность никогда не мешала (в моей практике как минимум)
* А если стало интересно разобраться, как например работают чаты, то webSocket и прочие радости тоже пригодятся.
👍1
* А еще я бы посоветовала изучить простые правила поддержания безопасности данных пользователя. Где на клиенте хранить пользовательские данные, как обезопасить от вредителей поля форм, почему не http, а https и пр.
learn.javanoscript.ru
Современный учебник JavaScript
Современный учебник JavaScript, начиная с основ, включающий в себя много тонкостей и фишек JavaScript/DOM.
👍1
Такое большое, что даже раздробилось! Список по TS будет ожидаемо меньше, скоро подготовлю)
Что необходимо знать TypeScript? (осторожно, субъективное мнение)
1. TypeScript часто воспринимается как «надстройка» над JavaScript. Потому что использует все, что есть в последнем и добавляет строгую типизацию.
2. TS не работает в среде выполнения. Он транспилируется (переводится) на этапе билда в JavaScript.
3. Придется поколдовать и подключить линтеры в проект.
4. Строгая типизация TS поможет вам только во время разработки, то есть, поможет вам своими же руками не пихать куб в круглое отверстие, однако не поможет на продакшене.
5. Типизировать надо все. Это дополнительная тренировка, даже если вам подсвечивает типы среда разработки, написать прописать тип лишним не будет. Хорошие привычки надо прививать с самого начала.
6. Придется научиться работать не только с типами, вшитыми в JS, но и с типами, предоставляемыми TS.
7. TS не умеет понимать, что происходит во встроенных методах JS (таких как map, filter, reducer и т.д.). Значит следить за описанием типов аргументов в коллбеке и типа результата, который метод возвращает — ваша ответственность.
Кстати, про последнее. Это интересная особенность обусловлена тем, что в JS массив может быть содержать одновременно сроки, числа, массивы, объекты и функции. TS тут умывает руки и отказывается строить догадки. Просто считает неизвестным то, что внутри метода будет происходить, и что будут коллбеки возвращать.
Добавлю-ка я вам тут ложку дегтя.
Есть ряд разработчиков, которые отказываются от использования TS. Например, кажется в 2023, был скандал связанный с библиотекой Switle, где главный мейнтейнер, без предупреждения сообщества, взял и выпилил TS из кода библиотеки. А потом пояснил, что с разрастанием библиотеки поддерживать типизацию на должном уровне становится слишком сложно и ресурсоемко. Тут есть статья с пересказом его интервью. Кейс с полностью поддерживающей типы библиотекой уникален, потому что ты должен оформить типизацию с учетом того, что пользователь может передать в твои компоненты, и какие проблемы могут у него возникнуть.
Для всего остального есть TypeScript.
Зачем все усложнять, если на проде все равно JS?
Представьте, что вам нужно перевести легаси проект на TS, даже который писали не джуны. Скоре всего вы столкнетесь с конфликтом: в некоторый функции уже передается что-то, что не ожидали ранее. Или сторонняя библиотека, которую вы используете, все это время передавала вам нечто, что работало, но вид имело отличающийся от ожидаемого. Это могло повлечь ошибки, но вам повезло.
Если не хотите неожиданностей и пишете на JS, надо проверять все и отлично понимать механизм неявной типизации. Что приходит в функцию? А всегда? А только такое может прийти? А точно? А что вам на самом деле возвращает ваш редьюсер? А что будет с кодом, вызывающим ваш редьюсер, если тот вернет пустой объект, например? А во всех местах вызова этой функции?
Из общепринятых положительных аспектов, можно отметить:
- Стабильность работы кода
- Отсутствие ляпов, такие как: «Добро пожаловать, undefined/[Object Object]». Вероятность косяка сохраняется, особенно есть оставляете где попало any, но уже меньше, если не играете в упрощение.
- Если используемая функция вызывается в множестве мест, точно не сможете передать то, что в ней не ожидается.
- Наверняка сюда же можно добавить повышение читабельности кода. Но тут как посмотреть. Если вы только начали изучение TS, то код будет казаться сильно сложнее, чем должен быть. А если вы на опыте, то как раз наоборот. Не надо додумывать и держать в голове, что приходит и откуда, куда уходит, какие проверки надо добавить, чтобы в продакшене случайно не крашнулась страница или отправка формы с 100500 полями.
Так с вводной частью закончили, приступаем у тому, что вы хотели (как мне кажется).
Что нужно знать в TypeScript?
Вообще, конечно, вот вам полная документация из первых рук, тут есть все, но на английском. Читайте доку поэтапно или по мере необходимости. Так же как и со списком о JS — это не гайд, а рекомендация и не на джуна или мидла, а к чему стоит стремиться на мой вкус. Короче, снова будут только опорные точки.
1. TypeScript часто воспринимается как «надстройка» над JavaScript. Потому что использует все, что есть в последнем и добавляет строгую типизацию.
2. TS не работает в среде выполнения. Он транспилируется (переводится) на этапе билда в JavaScript.
3. Придется поколдовать и подключить линтеры в проект.
4. Строгая типизация TS поможет вам только во время разработки, то есть, поможет вам своими же руками не пихать куб в круглое отверстие, однако не поможет на продакшене.
5. Типизировать надо все. Это дополнительная тренировка, даже если вам подсвечивает типы среда разработки, написать прописать тип лишним не будет. Хорошие привычки надо прививать с самого начала.
6. Придется научиться работать не только с типами, вшитыми в JS, но и с типами, предоставляемыми TS.
7. TS не умеет понимать, что происходит во встроенных методах JS (таких как map, filter, reducer и т.д.). Значит следить за описанием типов аргументов в коллбеке и типа результата, который метод возвращает — ваша ответственность.
Кстати, про последнее. Это интересная особенность обусловлена тем, что в JS массив может быть содержать одновременно сроки, числа, массивы, объекты и функции. TS тут умывает руки и отказывается строить догадки. Просто считает неизвестным то, что внутри метода будет происходить, и что будут коллбеки возвращать.
Добавлю-ка я вам тут ложку дегтя.
Есть ряд разработчиков, которые отказываются от использования TS. Например, кажется в 2023, был скандал связанный с библиотекой Switle, где главный мейнтейнер, без предупреждения сообщества, взял и выпилил TS из кода библиотеки. А потом пояснил, что с разрастанием библиотеки поддерживать типизацию на должном уровне становится слишком сложно и ресурсоемко. Тут есть статья с пересказом его интервью. Кейс с полностью поддерживающей типы библиотекой уникален, потому что ты должен оформить типизацию с учетом того, что пользователь может передать в твои компоненты, и какие проблемы могут у него возникнуть.
Для всего остального есть TypeScript.
Зачем все усложнять, если на проде все равно JS?
Представьте, что вам нужно перевести легаси проект на TS, даже который писали не джуны. Скоре всего вы столкнетесь с конфликтом: в некоторый функции уже передается что-то, что не ожидали ранее. Или сторонняя библиотека, которую вы используете, все это время передавала вам нечто, что работало, но вид имело отличающийся от ожидаемого. Это могло повлечь ошибки, но вам повезло.
Если не хотите неожиданностей и пишете на JS, надо проверять все и отлично понимать механизм неявной типизации. Что приходит в функцию? А всегда? А только такое может прийти? А точно? А что вам на самом деле возвращает ваш редьюсер? А что будет с кодом, вызывающим ваш редьюсер, если тот вернет пустой объект, например? А во всех местах вызова этой функции?
Из общепринятых положительных аспектов, можно отметить:
- Стабильность работы кода
- Отсутствие ляпов, такие как: «Добро пожаловать, undefined/[Object Object]». Вероятность косяка сохраняется, особенно есть оставляете где попало any, но уже меньше, если не играете в упрощение.
- Если используемая функция вызывается в множестве мест, точно не сможете передать то, что в ней не ожидается.
- Наверняка сюда же можно добавить повышение читабельности кода. Но тут как посмотреть. Если вы только начали изучение TS, то код будет казаться сильно сложнее, чем должен быть. А если вы на опыте, то как раз наоборот. Не надо додумывать и держать в голове, что приходит и откуда, куда уходит, какие проверки надо добавить, чтобы в продакшене случайно не крашнулась страница или отправка формы с 100500 полями.
Так с вводной частью закончили, приступаем у тому, что вы хотели (как мне кажется).
Что нужно знать в TypeScript?
Вообще, конечно, вот вам полная документация из первых рук, тут есть все, но на английском. Читайте доку поэтапно или по мере необходимости. Так же как и со списком о JS — это не гайд, а рекомендация и не на джуна или мидла, а к чему стоит стремиться на мой вкус. Короче, снова будут только опорные точки.
👍1
1. Зарубите себе и окружающим на носу: any — игрушка дьявола. Он отключает проверку типов. Совсем. Навсегда. В том месте, где использован. Лучше заморочится, но придумать выход из положения, чем оставить any в коде. Однако признаюсь, я не без греха. Иногда при использовании сторонних библиотек, в которых нет типизации, я оставляю any до лучших времен. Но при этом, мне об any в коде каждый билд напоминают литеры.
2. Из первого вытекает, что стоит знать разницу между any, unknown, never и void, чтобы уместно их использовать.
3. Utility Types: может казаться перебором, но чем дальше в лес тем все полезнее будет знать, что подходящий утилитный тип существует. Например, при типизации данных с API или функций, в которые попадают разного типа объекты, с которыми надо сделать одинаковые манипуляции, вернув при этом тот же тип, но, например, только с частью полей. (При этом сохранив проверки на выходе для дальнейшего использования полученного объекта)
4. Разницу между type и interface тоже не забудьте чекнуть. Хотя в больших проектах иногда используется interface там, где хватило бы и type. Это уже вопрос конвенций внутри проекта. Об этом тоже как-нибудь поговорим.
5. Дженерики. По началу я отказывалась их использовать, потому что не понимала всей красоты и удобства, но на сколько люблю их сейчас не передать. Они помогают зачастую элегантно решить то, что кажется не решаемым совсем. Советую от всего сердца разобраться, понять и полюбить.
6. Отдельный уровень это Conditional types. Это какой-то новый уровень для меня. Буквально две недели назад первый раз пришлось использовать. И скажу вам в моменте взрывается мозг, когда ты можешь прописать тип через тернарное условие. Вау.
7. Mapped types тоже полезная штука.
8. Ну и последнее, как я писала ранее, сейчас мы не так часто пишем руками конструкторы классов, но обратите внимание, что в TS классы и констукторы классов не типизируются через знакомые нам интерфейсы объектов.
В целом, список закончился.
На мой взгляд, пользя от изучение TS в отрыве от практики стремиться к 0. Вы скорее всего просто не придумаете такие заковыристые кейсы без реального опыта. Но попытаться все же изучить стоит. Если знаете о существовании инструментов, то в нужный момент они вспомнятся отдаленным эхом, вы залезете в документацию и найдете что нужно.
Мой личный опыт использования TS: через боль к стокгольмскому синдрому)
Поясню, я как-то попала на проект, где надо было переиспользовать и доработать стороннюю библиотеку. Не форком, а затягиванием ее в проект. И библиотека, ожидаемо была типизирована частично. Сколько раз я получила нагоняй от лида за any и uknown не сосчитать, зато научилась типизировать (более или менее).
До сих пор я узнаю и пробую новые приемы, могу сказать, что уровень владения типизацией подрос. И тем быстрее он растет, чем более требовательна я к себе в этом вопросе. И не смотря на то, что решения по типизации порой выглядят громоздко и не очень понятно (в какой-то степени для меня и моих коллег), это дает мне уверенность в стабильности работы моего кода. А закрытые гештальты — это приятно.
2. Из первого вытекает, что стоит знать разницу между any, unknown, never и void, чтобы уместно их использовать.
3. Utility Types: может казаться перебором, но чем дальше в лес тем все полезнее будет знать, что подходящий утилитный тип существует. Например, при типизации данных с API или функций, в которые попадают разного типа объекты, с которыми надо сделать одинаковые манипуляции, вернув при этом тот же тип, но, например, только с частью полей. (При этом сохранив проверки на выходе для дальнейшего использования полученного объекта)
4. Разницу между type и interface тоже не забудьте чекнуть. Хотя в больших проектах иногда используется interface там, где хватило бы и type. Это уже вопрос конвенций внутри проекта. Об этом тоже как-нибудь поговорим.
5. Дженерики. По началу я отказывалась их использовать, потому что не понимала всей красоты и удобства, но на сколько люблю их сейчас не передать. Они помогают зачастую элегантно решить то, что кажется не решаемым совсем. Советую от всего сердца разобраться, понять и полюбить.
6. Отдельный уровень это Conditional types. Это какой-то новый уровень для меня. Буквально две недели назад первый раз пришлось использовать. И скажу вам в моменте взрывается мозг, когда ты можешь прописать тип через тернарное условие. Вау.
7. Mapped types тоже полезная штука.
8. Ну и последнее, как я писала ранее, сейчас мы не так часто пишем руками конструкторы классов, но обратите внимание, что в TS классы и констукторы классов не типизируются через знакомые нам интерфейсы объектов.
В целом, список закончился.
На мой взгляд, пользя от изучение TS в отрыве от практики стремиться к 0. Вы скорее всего просто не придумаете такие заковыристые кейсы без реального опыта. Но попытаться все же изучить стоит. Если знаете о существовании инструментов, то в нужный момент они вспомнятся отдаленным эхом, вы залезете в документацию и найдете что нужно.
Мой личный опыт использования TS: через боль к стокгольмскому синдрому)
Поясню, я как-то попала на проект, где надо было переиспользовать и доработать стороннюю библиотеку. Не форком, а затягиванием ее в проект. И библиотека, ожидаемо была типизирована частично. Сколько раз я получила нагоняй от лида за any и uknown не сосчитать, зато научилась типизировать (более или менее).
До сих пор я узнаю и пробую новые приемы, могу сказать, что уровень владения типизацией подрос. И тем быстрее он растет, чем более требовательна я к себе в этом вопросе. И не смотря на то, что решения по типизации порой выглядят громоздко и не очень понятно (в какой-то степени для меня и моих коллег), это дает мне уверенность в стабильности работы моего кода. А закрытые гештальты — это приятно.
DEVCLASS
TypeScript is 'not worth it' for developing libraries, says Svelte author, as team switches to JavaScript and JSDoc • DEVCLASS
Svelte creator Rich Harris has made the case for switching from TypeScript to JavaScript and JSDoc, countering a […]
👍1
Про тренировку TS на практике отдельно
Есть тренажер по TS. Я с сомнением к нему отношусь, потому что он как домашка к документации. Прочитал часть доки и проверяешь, на сколько ты ее понял. Не получается, вот ссылка на статью в доке, топай перечитывать. Но, как мне видится, он не так много дает в понимании, к какому реальному кейсу его применить.
Еще у меня есть пара интересных задач, которые я даю своим менти (в основном около джунам). Хотите поделюсь?
Есть тренажер по TS. Я с сомнением к нему отношусь, потому что он как домашка к документации. Прочитал часть доки и проверяешь, на сколько ты ее понял. Не получается, вот ссылка на статью в доке, топай перечитывать. Но, как мне видится, он не так много дает в понимании, к какому реальному кейсу его применить.
Еще у меня есть пара интересных задач, которые я даю своим менти (в основном около джунам). Хотите поделюсь?
typenoscript-exercises.github.io
TypeScript Exercises
A set of interactive TypeScript exercises
👍1
Про семантику HTML5
Про семантику говорить веселее всего, на мой вкус.
Еще каких-то несколько лет назад, на вопрос на собесе о семантикческой верстке все отвечали стандартной фразой, но мало кто в реальности придерживался семантики.
Почему? Потому что основная разработка web-приложений ведется через библиотеки и фреймворки, а сними была беда. Сделать так, чтобы твое приложение на React или Angular парсилось как надо, нужно было долго и мучительно плясать с бубнами. Но и это было плюс минус бесполезно.
Потом, от части, чтобы решить эту проблему начали рождать SSR и SSG решения (NextJS или NustJS, например). Они позволяют подгружать готовые страницы, а значит и парсеры могут их переварить.
Для всего остального же были div’ы. И многие фронтендеры просто игнорировали семантические теги. А зря конечно. Как говориться дурное дело не хитрое.
Так стоп. Парсеры, семантическая верстка, как они связаны? По порядку)
Парсеры — поисковые парсеры, которые считывают и индексируют вашу страницу в поисковиках. Уровень индексации зависит как от семантичности разметки, так и от ее валидности.
Что такое семантическая верстка в целом?
Семантическая верстка появилась вместе с HTML5, то есть очень давно, и принесла особенные отметки для поисковых парсеров. Если все написать на дивах и бахнуть различия только стилями, для парсеров это будет белым шумом, они не заметят вашу страницу.
Основной эффект: Чем выше уровень семантичности разметки и валидности на вашей странице, тем выше индекс вам поставит парсер. А более высокий индекс, значит, что нативно ваша страница поднимется в поиске выше. Что не может не порадовать вашего SEO 🎉.
Думаю, что перечислять все семантические теги утомительно, так что вот полный список тегов в уелом, и список семантических тегов в частности.
Только из-за парсеров писать семантику что ли? Нет, не только.
Для удобства разработчика: когда читаешь код, проще понять какой блок за что отвечает, не надо выискивать глазами классы.
Если соблюдаешь правила, то проще сделать твою страницу более доступной. Например не забыть про label, или расположить твои заголовки в убывающем порядке, как положено.
Подытожим — обычно говорят, что у семантика нужна для:
1) видимости вашей страницы для парсера и возможности подняться в поисковикебез регистрации и смс онлайн
2) удобство чтения кода, аккуратность его оформления
3) ну и повышение уровня доступности (даже неосознанно)
Про доступность, кстати, есть отдельный пост тут)
Теперь к практическим штукам:
На сколько мне известно, автоматом проверить на сколько ваша страница получилась семантичной нельзя. Придется всматриваться и проверять глазами.
А вот на валидность проверить автоматом и получить рекомендации можно. Работает просто:
Загружаете файл или урл, а валидатор подсвечивает ошибки и их критичность. Например, может разглядеть опечатку, отсутствие необходимого атрибута или незакрытый тег. Но отличить, что вы использовали span вместо h3 — нет.
Так что доверяй, но на семантику сам проверяй.
Про семантику говорить веселее всего, на мой вкус.
Еще каких-то несколько лет назад, на вопрос на собесе о семантикческой верстке все отвечали стандартной фразой, но мало кто в реальности придерживался семантики.
Почему? Потому что основная разработка web-приложений ведется через библиотеки и фреймворки, а сними была беда. Сделать так, чтобы твое приложение на React или Angular парсилось как надо, нужно было долго и мучительно плясать с бубнами. Но и это было плюс минус бесполезно.
Потом, от части, чтобы решить эту проблему начали рождать SSR и SSG решения (NextJS или NustJS, например). Они позволяют подгружать готовые страницы, а значит и парсеры могут их переварить.
Для всего остального же были div’ы. И многие фронтендеры просто игнорировали семантические теги. А зря конечно. Как говориться дурное дело не хитрое.
Так стоп. Парсеры, семантическая верстка, как они связаны? По порядку)
Парсеры — поисковые парсеры, которые считывают и индексируют вашу страницу в поисковиках. Уровень индексации зависит как от семантичности разметки, так и от ее валидности.
Что такое семантическая верстка в целом?
Семантическая верстка появилась вместе с HTML5, то есть очень давно, и принесла особенные отметки для поисковых парсеров. Если все написать на дивах и бахнуть различия только стилями, для парсеров это будет белым шумом, они не заметят вашу страницу.
Основной эффект: Чем выше уровень семантичности разметки и валидности на вашей странице, тем выше индекс вам поставит парсер. А более высокий индекс, значит, что нативно ваша страница поднимется в поиске выше. Что не может не порадовать вашего SEO 🎉.
Думаю, что перечислять все семантические теги утомительно, так что вот полный список тегов в уелом, и список семантических тегов в частности.
Только из-за парсеров писать семантику что ли? Нет, не только.
Для удобства разработчика: когда читаешь код, проще понять какой блок за что отвечает, не надо выискивать глазами классы.
Если соблюдаешь правила, то проще сделать твою страницу более доступной. Например не забыть про label, или расположить твои заголовки в убывающем порядке, как положено.
Подытожим — обычно говорят, что у семантика нужна для:
1) видимости вашей страницы для парсера и возможности подняться в поисковике
2) удобство чтения кода, аккуратность его оформления
3) ну и повышение уровня доступности (даже неосознанно)
Про доступность, кстати, есть отдельный пост тут)
Теперь к практическим штукам:
На сколько мне известно, автоматом проверить на сколько ваша страница получилась семантичной нельзя. Придется всматриваться и проверять глазами.
А вот на валидность проверить автоматом и получить рекомендации можно. Работает просто:
Загружаете файл или урл, а валидатор подсвечивает ошибки и их критичность. Например, может разглядеть опечатку, отсутствие необходимого атрибута или незакрытый тег. Но отличить, что вы использовали span вместо h3 — нет.
Так что доверяй, но на семантику сам проверяй.
👍1
CSS селекторы и их "Вес"
Вы наверняка знакомы с селекторами, но хочется закрепить всю базу в одном месте.
Что такое селекторы?
Каждый из этих примеров селектор. Некоторых путает, когда они читают что-то вроде:
На самом же деле, селектор — это набор, или комбинация, простых селекторов, которые по сути указывают адрес того или этого элемента страницы. Прямо как «город, улица, дом, корпус, квартира»
Таким образом мы можем создать несколько разных селекторов, указывающие на один и тот же элемент. Чтобы браузеру разрешить этот конфликт интересов и применить «нужный»? Браузер ориентируется на такое понятие, как «Вес селектора»
Что такое «Вес селектора»?
Это код из 4 цифр (0 0 0 0), с помощью которых браузер может понять приоритет.
1 0 0 0 — идентификатор (#footer)
0 1 0 0 — классы (.footer)
0 0 1 0 — теги (footer)
Кажется понятные типы селекторов закончились, а порядковые значения нет 🧐. Именно про них часто и забывают.
0 0 0 1 — псевдоселекторы и псевдоклассы ( :hover, :lasх-child, :before и др)
Итого: Вес селектора складывается и того, какое количество и какого типа одиночных селекторов в нем комбинируются.
Посмотрим на пример, который мне однажды попадался на собеседовании:
Какого цвета в итоге будет текст в span? Можете проверить себя в голосовашке после. А если пока сложно, то в спойлеры будет объяснение. Не открывайте, пока сами не подумаете над задачкой, так будет интереснее)
Для начала нам надо понять какой у каждого селектора будет вес. 1 — 0 1 0 0, 2 — 0 1 1 0, 3 — 0 1 0 0, 4 — 0 0 1 0. Если так все еще не понятно, давайте проигнорируем лишние нули справа и посчитаем в рублях, че нет. 1 — 100р, 2 — 110р, 3 — 100р, 4 — 10р. А теперь просто выберете тот селектор, который весит «больше всего».
Так же работает, если у вас есть и идентификаторы и псевдоним селекторы. Еще один примерчик:
Посчитаем?
#bahher — Идентификатор 1 шт => 1 0 0 0 — 1000
.banner-menu .banner-menu__item — Класс 2 шт => 0 2 0 0 — 200
Тег 0 шт => 0 0 0 0 — 0
.banner-menu__item:hover — Псевдокласс или псевдоселектор 1 шт => 0 0 0 1 — 1
А теперь складываем 1000 + 200 + 0 + 1 = 1201 => вес нашего селектора 1 2 0 1.
Зачем мне надо это знать? Звучит как фигня для браузера.
Все просто, представьте, что вам надо отредактировать сайт компании, в которой вы работаете, или пришел заказ на дароботку лендоса, который вы год назад отдали заказчику. Помните ли вы что и как писали в этом проекте? Скорее всего нет. И вот вы вносите новый селектор, чтобы изменить цвет какой-нибудь кнопки, а это не срабатывает. Что это значит? Значит, что где-то есть селектор с более высоким приоритетом чем у вас.
Логично просто заменить цвет в предыдущем селекторе. Оп, а это ловушка, теперь все кнопки на странице поменяли цвет, а вам нужна только одна. Что делать? Уточнитьадрес комбинацию селекторов, чтобы поднять вес и сделать ваш селектор более приоритетным.
Ну что, на вопрос зачем ответили. Но я у себя в голове слышу надоедливый голос, который спрашивает:
«А как же импортант или онлайн стили? Они же важнее в сто крат!»
Разберемся, а то не отстанет же.
Во первых да, любую комбинацию можно перебить с помощью !important или инлайн-стилей (это те стили, которые в пишете в атрибуте style в самом теге)
Вернемся на секундочку в пример со span’ом:
Теперь цвет текста будет розовый
Вы наверняка знакомы с селекторами, но хочется закрепить всю базу в одном месте.
Что такое селекторы?
.footer {}
footer {}
.article footer {}
.menu-list .menu-list__item:last-child {}
.menu-list .menu-list__item_active {}Каждый из этих примеров селектор. Некоторых путает, когда они читают что-то вроде:
«Селекторы бывают разных типов по классу, по тегу, по идентификатору».
На самом же деле, селектор — это набор, или комбинация, простых селекторов, которые по сути указывают адрес того или этого элемента страницы. Прямо как «город, улица, дом, корпус, квартира»
Таким образом мы можем создать несколько разных селекторов, указывающие на один и тот же элемент. Чтобы браузеру разрешить этот конфликт интересов и применить «нужный»? Браузер ориентируется на такое понятие, как «Вес селектора»
Что такое «Вес селектора»?
Это код из 4 цифр (0 0 0 0), с помощью которых браузер может понять приоритет.
1 0 0 0 — идентификатор (#footer)
0 1 0 0 — классы (.footer)
0 0 1 0 — теги (footer)
Кажется понятные типы селекторов закончились, а порядковые значения нет 🧐. Именно про них часто и забывают.
0 0 0 1 — псевдоселекторы и псевдоклассы ( :hover, :lasх-child, :before и др)
Итого: Вес селектора складывается и того, какое количество и какого типа одиночных селекторов в нем комбинируются.
Посмотрим на пример, который мне однажды попадался на собеседовании:
<span class="text note">Какого я цвета?</span>
.text {
color: red;
}
span.text {
color: green;
}
.note {
color: blue;
}
span {
color: pink;
}
Какого цвета в итоге будет текст в span? Можете проверить себя в голосовашке после. А если пока сложно, то в спойлеры будет объяснение. Не открывайте, пока сами не подумаете над задачкой, так будет интереснее)
Так же работает, если у вас есть и идентификаторы и псевдоним селекторы. Еще один примерчик:
#bahher .banner-menu .banner-menu__item .banner-menu__item:hover
Посчитаем?
#bahher — Идентификатор 1 шт => 1 0 0 0 — 1000
.banner-menu .banner-menu__item — Класс 2 шт => 0 2 0 0 — 200
Тег 0 шт => 0 0 0 0 — 0
.banner-menu__item:hover — Псевдокласс или псевдоселектор 1 шт => 0 0 0 1 — 1
А теперь складываем 1000 + 200 + 0 + 1 = 1201 => вес нашего селектора 1 2 0 1.
Зачем мне надо это знать? Звучит как фигня для браузера.
Все просто, представьте, что вам надо отредактировать сайт компании, в которой вы работаете, или пришел заказ на дароботку лендоса, который вы год назад отдали заказчику. Помните ли вы что и как писали в этом проекте? Скорее всего нет. И вот вы вносите новый селектор, чтобы изменить цвет какой-нибудь кнопки, а это не срабатывает. Что это значит? Значит, что где-то есть селектор с более высоким приоритетом чем у вас.
Логично просто заменить цвет в предыдущем селекторе. Оп, а это ловушка, теперь все кнопки на странице поменяли цвет, а вам нужна только одна. Что делать? Уточнить
Ну что, на вопрос зачем ответили. Но я у себя в голове слышу надоедливый голос, который спрашивает:
«А как же импортант или онлайн стили? Они же важнее в сто крат!»
Разберемся, а то не отстанет же.
Во первых да, любую комбинацию можно перебить с помощью !important или инлайн-стилей (это те стили, которые в пишете в атрибуте style в самом теге)
Вернемся на секундочку в пример со span’ом:
<span class="text note">Какого я цвета?</span>
.text {
color: red;
}
span.text {
color: green;
}
.note {
color: blue;
}
span {
color: pink !important;
}
Теперь цвет текста будет розовый
Telegram
О фронтенде с любовью
Какого цвета в итоге будет текст в span? (первый пример из поста про вес селекторов)
красный / зеленый / синий / розовый
красный / зеленый / синий / розовый
👍1
<span class="text note" style={{color: yellow}}>Какого я цвета?</span>
.text {
color: red;
}
span.text {
color: green;
}
.note {
color: blue;
}
span {
color: pink !important;
}А теперь
Тут кроется самый большой минус: Если вы так фиксанете или сразу напишете стили, вам потом будет очень непросто или даже невозможно управлять стилями из CSS. Что может привести к большой путанице и новым багулям.
Зачем он тогда остался? Это тот самый рудимент, да? Неа. !important, как и инлайн-стили, штука полезная, например, если вам надо поменять цвет элемента, который берете из сторонней библиотеки, и ваши стили игнорируются. Вы можете использовать встроенный селектор для этого элемента, и с помощью !important «перебить» изначальное значение какого-нибудь свойства.
И да, если есть инлайн-стили или !important браузер просто забивает на вес селекторов к одному и тому же элементу и применяет их.
Получается слишком длинный пост, да еще и с голосовалокой, так что про то, как можно достучаться до разного рода соседних или получить доступ к элементам с определенным атрибутом в следующем посте 😅
P.s: Что-то прояснилось или вы уже все это и так знали, маякните в комменте, мне очень интересно!
👍1
Какого цвета в итоге будет текст в span? (первый пример из поста про вес селекторов)
Anonymous Quiz
0%
красный
0%
зеленый
50%
синий
50%
розовый
Как заметить свой рост
Пока готовятся задания по TS, хочу поделиться с вами тем, что очень порадовало меня недавно.
Некоторые из вас знают, что раньше я преподавала фронтенд на курсах на базе одного из местных универов. И в этом году меня позвали быть преподавателем снова, что очень приятно (привет студентам 😅). К предыдущим годам обучения я готовила часть презентации для лекций, составляла тесты, для проверки усваиваемости материалов, и практические задания. А после был перерыв в преподавании 1,5 года.
И вот я получила доступ к своей презентаций снова и осознала
- барабанная дробь -
что мои презентации из прошлого не настолько полные, как этого хотелось бы! А это значит, что и я знала меньше, чем сейчас. Материалы нормальные, дают базу и по ним можно учиться, но, спустя время, я знаю больше фишек и нюансов, которыми можно поделиться.
Что это значит для меня?
Для меня этот факт — материальное доказательство моего роста как специалиста. Ура-ура)
В прошлом году моё внимание привлекла статья про самообучение, и мы позвали автора в подкаст "Помогите, я джун" (кстати выпуск можно послушать в Яндекс или на Ютубе). В том выпуске мы с Дмитрием обсуждали пользу от ведения заметок по тому, что ты изучил (сохранять их только для себя или делиться ими на аудиторию) и о том, что это дает — позволяет лучше структурировать для себя полученные знания. А еще через время, можно вернуться и увидеть разницу глубины знания тогда и сейчас.
А теперь мотивационная часть, которая вдохновила меня.
Когда мы долго работаем над собой или в профессии, мы часто не обращаем внимания на то, как происходит наш рост и не можем зафиксировать и отметить его для себя. Нам начинает казаться, что мы не растем вовсе. А это отличная почва для того же синдрома самозванца.
Вывод и напутствие очень простые:
попробуйте найти свой способ фиксировать уровень, не забывайте возвращаться к предыдущим результатам для оценки и хвалить себя за новые знания и умения.
Тогда ваша внутренняя мотивация будет регулярно подпитываться на основе фактов, а не пустой бравады.
А что если я вернусь и не увижу роста?
Что ж, такое тоже может быть. Что это будет значить для вас, вам предстоит выяснить самостоятельно. Но для меня это было бы показателем того, что я занимаюсь чем-то не тем, неверно расставляю приоритеты или выбрала не ту профессию.
Пока готовятся задания по TS, хочу поделиться с вами тем, что очень порадовало меня недавно.
Некоторые из вас знают, что раньше я преподавала фронтенд на курсах на базе одного из местных универов. И в этом году меня позвали быть преподавателем снова, что очень приятно (привет студентам 😅). К предыдущим годам обучения я готовила часть презентации для лекций, составляла тесты, для проверки усваиваемости материалов, и практические задания. А после был перерыв в преподавании 1,5 года.
И вот я получила доступ к своей презентаций снова и осознала
- барабанная дробь -
что мои презентации из прошлого не настолько полные, как этого хотелось бы! А это значит, что и я знала меньше, чем сейчас. Материалы нормальные, дают базу и по ним можно учиться, но, спустя время, я знаю больше фишек и нюансов, которыми можно поделиться.
Что это значит для меня?
Для меня этот факт — материальное доказательство моего роста как специалиста. Ура-ура)
В прошлом году моё внимание привлекла статья про самообучение, и мы позвали автора в подкаст "Помогите, я джун" (кстати выпуск можно послушать в Яндекс или на Ютубе). В том выпуске мы с Дмитрием обсуждали пользу от ведения заметок по тому, что ты изучил (сохранять их только для себя или делиться ими на аудиторию) и о том, что это дает — позволяет лучше структурировать для себя полученные знания. А еще через время, можно вернуться и увидеть разницу глубины знания тогда и сейчас.
А теперь мотивационная часть, которая вдохновила меня.
Когда мы долго работаем над собой или в профессии, мы часто не обращаем внимания на то, как происходит наш рост и не можем зафиксировать и отметить его для себя. Нам начинает казаться, что мы не растем вовсе. А это отличная почва для того же синдрома самозванца.
Вывод и напутствие очень простые:
попробуйте найти свой способ фиксировать уровень, не забывайте возвращаться к предыдущим результатам для оценки и хвалить себя за новые знания и умения.
Тогда ваша внутренняя мотивация будет регулярно подпитываться на основе фактов, а не пустой бравады.
А что если я вернусь и не увижу роста?
Что ж, такое тоже может быть. Что это будет значить для вас, вам предстоит выяснить самостоятельно. Но для меня это было бы показателем того, что я занимаюсь чем-то не тем, неверно расставляю приоритеты или выбрала не ту профессию.
Хабр
Как учиться учиться и для чего интровертам телеграм-канал
«Лучший способ в чём-то разобраться до конца — это попробовать научить этому компьютер». Дональд Кнут ( как минимум викицитатник говорит, что он так сказал ). Год назад я осознал, что моё развитие как...
❤🔥7❤1