Осуждение вполне обосновано. Хочет чувак учиться, пускай идёт и учится. Курсов полно. Написание статьи и обучение, различные вещи. Какой опыт вы сможете перенять у человека с сомнительным опытом?
Я просто даже боюсь представить стоимость такого специалиста. А это точно тестировщик, может ошибка в названии статьи? Предлагаю изменить название и контекст статьи. «Что должен знать T-Shape инженер бекенда?» Как посмотрю последнее время необоснованно растут требования к инженерам, но не растут зарплаты. А вообще это уже вопрос перекладывания ответственности за архитектуру и процессы разработки с (Тим, тех, арх и прочих лидов) на линейных специалистов. Мы вам скажем на словах что нужно, а вы уж сами там принимайте решения и думайте как лучше сделать. Вот с таких предпосылок и растут ноги у подобных «что должен знать дворник Палыч о свойствах пыли».
С таким подходом и лиды не нужны. Ведь Тшейпы всё уже сами знают, смогут договориться в виду своей разносторонней подкованности. Да и к чему такие лиды, которые не знают о процессах производства и не способны использовать узкие специализации в разработке ПО. Такие лиды будут искать дешевых сотрудников знающих всё и тратить на это уйму времени. С одной стороны можно методически подойти к процессу разработки, выдать каждому сотруднику свой фронт работы, заложить бюджет на изучение необходимой спецификации или опять же самому подготовить методику работы с той или иной технологией (коли семь пядей во лбу) и т.д. но ведь это сложно, проще ждать «необходимого сотрудника». Но вот с другой стороны такой необходимый сотрудник тратит своё время на изучение каждой технологии, держит свои знания в актуальном состоянии, тратит на это ресурсы (кстати время это тоже ресурс) и для чего? Что-бы кто-то «условно бесплатно» это получил просто прицепом к должности «тестировщик». А тестировщик должен знать, как раз то чему выделен жалкий абзац в этой статье, а именно теорию тестирования и соответственно навыки владения языком в контексте которого тестируется система. Всё остальное уже как раз тот прицеп за который компания должна либо доплачивать, либо обучать.
//сущность tomSon давно уже создана, но мы добавляем свойства в её прототип и можем реализовать в ней поведение, которое будет оперировать этими свойствами
учитывая тот факт, что метод добавлен непосредственно в объект (в представленном коде), а не в его прототип, в этом поможет убедиться состав объекта на которое ссылается свойство __proto__
Соответсвенно и последующие рассуждения искажаются допущенным недопониманием рассматриваемого вопроса
И это всё? Фабула оборвалась, просто, где-то на середине. Выводы где? То что водитель завтракал за рулём это не выводы, это основание для последующих выводов и больше тянут на содержание новостных лент, чем на полноценную статью. Я уж не говорю о каком либо анализе. Какое постановление суда, какие предписания, кто прав, кто виноват. Это где? Или надо удосужиться разобраться самим в иноязычном юридическом документе?
Просматривая комментарии к публикации я обнаружил претензии следующего рода.
Монструозность (много текста в jpg)
Есть иные шпаргалки и руководства
во многом я соглашусь, особенно с тем что имеются иные руководства и шпаргалки (очень даже хорошие), однако в большинстве своём это не менее объемные массивы текста и иллюстраций. Моя цель была свести всё в одно-листовой массив «текста», для того что-бы можно было распечатать и положить перед глазами на период когда читатель ещё знакомится с технологией. А по поводу монструозности, тут уж простите у меня хворь на дизайн и графику, как технарь я постарался сделать более-менее опрятно. Я не претендую на оригинальность и приветствую критику по технической части. Укажите блок где неверная информация или бы по вашему мнению можно было иначе выразить-нарисовать-рассказать. Учту, поправлю. А так и на iPhone найдётся покупатель и на Android (это о предпочтениях). От себя добавлю в копилку отличную интерактивную шпаргалку
Приветствую и извиняюсь, что не нашел сразу времени ответить. Я немножечко в замешательстве, потому что не могу найти где у меня описана информация обратная вашему утверждению о расчете ширины элементов от свободного пространства в контейнере. Укажите пожалуйста фрагмент, где вы заметили ошибку. Т.к. просматривая текст я обнаружил несколько упоминаний об этом. У меня в описании св-ва flex-grow сказано, что элемент старается заполнить всё свободное пространство flex-контейнера. Более того приведена математическая формула расчета ширины flex-элемента, где так же фактор свободного пространства очевиден. И кстати говоря он находится в прямой зависимости от ширины контейнера (это о значении общей ширины). К формуле прилагается пример ниже где проведён расчет каждого параметра по шагам. И так же имеется краткое описание каждого компонента формулы.
С таким подходом и лиды не нужны. Ведь Тшейпы всё уже сами знают, смогут договориться в виду своей разносторонней подкованности. Да и к чему такие лиды, которые не знают о процессах производства и не способны использовать узкие специализации в разработке ПО. Такие лиды будут искать дешевых сотрудников знающих всё и тратить на это уйму времени. С одной стороны можно методически подойти к процессу разработки, выдать каждому сотруднику свой фронт работы, заложить бюджет на изучение необходимой спецификации или опять же самому подготовить методику работы с той или иной технологией (коли семь пядей во лбу) и т.д. но ведь это сложно, проще ждать «необходимого сотрудника». Но вот с другой стороны такой необходимый сотрудник тратит своё время на изучение каждой технологии, держит свои знания в актуальном состоянии, тратит на это ресурсы (кстати время это тоже ресурс) и для чего? Что-бы кто-то «условно бесплатно» это получил просто прицепом к должности «тестировщик». А тестировщик должен знать, как раз то чему выделен жалкий абзац в этой статье, а именно теорию тестирования и соответственно навыки владения языком в контексте которого тестируется система. Всё остальное уже как раз тот прицеп за который компания должна либо доплачивать, либо обучать.
учитывая тот факт, что метод добавлен непосредственно в объект (в представленном коде), а не в его прототип, в этом поможет убедиться состав объекта на которое ссылается свойство __proto__
Соответсвенно и последующие рассуждения искажаются допущенным недопониманием рассматриваемого вопроса
во многом я соглашусь, особенно с тем что имеются иные руководства и шпаргалки (очень даже хорошие), однако в большинстве своём это не менее объемные массивы текста и иллюстраций. Моя цель была свести всё в одно-листовой массив «текста», для того что-бы можно было распечатать и положить перед глазами на период когда читатель ещё знакомится с технологией. А по поводу монструозности, тут уж простите у меня хворь на дизайн и графику, как технарь я постарался сделать более-менее опрятно. Я не претендую на оригинальность и приветствую критику по технической части. Укажите блок где неверная информация или бы по вашему мнению можно было иначе выразить-нарисовать-рассказать. Учту, поправлю. А так и на iPhone найдётся покупатель и на Android (это о предпочтениях). От себя добавлю в копилку отличную интерактивную шпаргалку