Мне лично никогда не нравились вакансии в которых мне предлагали оценить свои знания по 10-бальной шкале. Потому что это нереально. Есть куча всяких нюансов в языке, конструкций, фреймворков. Поэтому единственный реальный профит от вопроса, это узнать, что человек достаточно умен, чтобы назвать цифру где-то посередине от 0 до 10.
Если к вам приходит Junior Developer это означает, что человек прочитал пару книжек, может вывести Hello World в консоль и катастрофически не имеет нормального опыта, который необходим для работы.
Я вспоминаю свое первое собеседование на позицию Junior Java Developer, как много я говорил слов невпопад:
1. Путал в сервлетах ServiceContext и RequestContext.
2. Не пользовался Idea, а писал в Notepad++.
3. Ничего не знал о Spring и Hibernate.
4. Не умел пользоваться debugger.
5. Не знал вообще Javascript и даже jQuery.
Первый месяц было очень тяжело, т.к. я чувствовал себя самым тупым человеком на свете, потому что тебе дают задачу, а ты элементарно не знаешь с какого конца приняться. Для коллег эта задачка была раз плюнуть и они быстро могли ее решить.
Поэтому надо просто брать человека и работать вместе с ним. Главное не то, сколько технологий он знает, а как быстро он может этому научится. Мы все были Junior, надо не забывать этого простого факта. Всем надо с чего-то начинать.
Поправка, после получения опыта сразу переходите в компании. В компаниях вы получаете один из самых ценных опытов: Работа в команде. Это очень важный навык, которым владеют очень немногие.
Начинающему админу удаленно никто не доверит инфраструктурой управлять. Он на то и начинающий. Получить опыт и знания не выезжая из родного города можно, но это тяжелее. Элементарно надо больше времени уделить на поиск и больше усилий приложить. А стоит ли это того или нет, каждый сам решает.
Ответ на вопрос. Если стоит вопрос почему стоит писать парсеры? То любой инструмент вроде Bem, Jade, React.JS, Emmet не обходится без парсинга. Поэтому парсить надо уметь, чтобы при случае применить свое знание.
Впрочем, все стоит помнить простое правило: Пользуйтесь уже проверенными, готовыми, покрытых тестами парсерами.
shouldComponentUpdate конечно решает. Но он увеличивает связанность кода от внешних props или state. В этом его главный минус, но для баг фиксинга и оптимизаций он отлично подходит.
В своей работе я рассматривал вариант отказаться от верхнего state и заменить его каким-нибудь хранилищем типа Cortex или Backbone.Model. В теории таким образом можно было бы избежать перерендеринга всех дочерних вьюх. Но теорию на практике не попробовал.
А в корневом виджете у нас находятся данные или состояние? В нем на мой взгляд стирается грань между тем и другим. По сути состояния хранящиеся в корневом виджете представляют из себя срез данных в конкретный момент времени. Они являются состоянием для приложения, но данными для дочерних View.
MVC-библиотека — библиотека, которая которая реализует паттерн MVC. Определение паттерну было дано выше. В целом довольно бесполезный спор на самом деле, т.к. предмет разговора очень субъективен. Он не несет никакой как практической ценности, так и теоретической. Относительно винегрета в моей голове предлагаю продолжить в ЛС.
Спасибо за трактовку. Теперь можно разобрать ее и убедиться почему React теоретически может являться MVC-библиотекой. Да странное название, но тем не менее.
Выдержки из трактовки:
Model
The model has two jobs: it must both store a state and manage subscribers. The state does not need to be anything special; you simply need to define how you're going to store data, with setters and getters. However, anything which can change (any property) must have a list of listeners which it contacts whenever the value changes.
Что мы видем в React? У нас есть state где происходит store a state, плюс у нас есть методы lifecycle у View, такие как: componentDidUpdate, componentWillUpdate, которые manage subscribers. State просто store data, и мы можем выполнить get data через this.state и произвести set через setState. Каждое изменение state прослушивается и при необходимости выполняет componentDidUpdate. В данном случае listener только один сама View у которой находится state.
View раскрывать не буду и так все ясно.
Controller
the parts which do not update when the model changes — are the responsibility of the controller. This includes navigating around the view, as well as what you do when someone tries to edit the data in the view. Strictly speaking, a view cannot be edited and is 'read-only' — when you try to modify a field in the view, the controller needs to pick up the editing event, process it, and send it to the model; the model will then update the view if/when the value actually changes.
Что мы видим. Благодаря shouldComponentUpdate, мы можем обновлять или не обновлять визуальное представление View в браузере. Плюс у нас есть методы handler, которые navigating around the view, as well as what you do when someone tries to edit the data in the view. И те самые callback, которые есть почти у каждого виджета, через которые мы возвращаем данные в корневой виджет для изменения state.
А далее controller needs to pick up the editing event, process it, and send it to the model; the model will then update the view if/when the value actually changes. Какое совпадение слово в слово совпадает с тем, как реализованы изменения в React.
Соглашусь, пожалуй. На мой взгляд именно View во всем Web-стеке самое уязвимое место для изменения требований, т.к. его видят абсолютно все и поэтому изменения и недоработки сразу видны. Поэтому многие предпочитают не углубляться глубоко и рефакторят именно View слой не затрагивая остальные.
Идеология React для меня это по возможности stateless-компоненты, которые предсказуемы и их поведение ожидаемо. Плюс тесная интеграция с внутренним состоянием всего приложения через state корневого виджета позволяет буквально сериализовывать все состояние приложения в одну команду. Естественно тут большую роль начинают играть алгоритмы для копирования данных state, т.к. надо работать с immutable данными.
Как правильно прочитать этот вопрос?
Мне лично никогда не нравились вакансии в которых мне предлагали оценить свои знания по 10-бальной шкале. Потому что это нереально. Есть куча всяких нюансов в языке, конструкций, фреймворков. Поэтому единственный реальный профит от вопроса, это узнать, что человек достаточно умен, чтобы назвать цифру где-то посередине от 0 до 10.
Если к вам приходит Junior Developer это означает, что человек прочитал пару книжек, может вывести Hello World в консоль и катастрофически не имеет нормального опыта, который необходим для работы.
Я вспоминаю свое первое собеседование на позицию Junior Java Developer, как много я говорил слов невпопад:
1. Путал в сервлетах ServiceContext и RequestContext.
2. Не пользовался Idea, а писал в Notepad++.
3. Ничего не знал о Spring и Hibernate.
4. Не умел пользоваться debugger.
5. Не знал вообще Javascript и даже jQuery.
Первый месяц было очень тяжело, т.к. я чувствовал себя самым тупым человеком на свете, потому что тебе дают задачу, а ты элементарно не знаешь с какого конца приняться. Для коллег эта задачка была раз плюнуть и они быстро могли ее решить.
Поэтому надо просто брать человека и работать вместе с ним. Главное не то, сколько технологий он знает, а как быстро он может этому научится. Мы все были Junior, надо не забывать этого простого факта. Всем надо с чего-то начинать.
Впрочем, все стоит помнить простое правило: Пользуйтесь уже проверенными, готовыми, покрытых тестами парсерами.
Решение для Linux.Кроссплатформенное решение. wiki.documentfoundation.org/Using_LibreOffice_in_a_Web_BrowserВыдержки из трактовки:
Model
The model has two jobs: it must both store a state and manage subscribers. The state does not need to be anything special; you simply need to define how you're going to store data, with setters and getters. However, anything which can change (any property) must have a list of listeners which it contacts whenever the value changes.
Что мы видем в React? У нас есть state где происходит store a state, плюс у нас есть методы lifecycle у View, такие как: componentDidUpdate, componentWillUpdate, которые manage subscribers. State просто store data, и мы можем выполнить get data через this.state и произвести set через setState. Каждое изменение state прослушивается и при необходимости выполняет componentDidUpdate. В данном случае listener только один сама View у которой находится state.
View раскрывать не буду и так все ясно.
Controller
the parts which do not update when the model changes — are the responsibility of the controller. This includes navigating around the view, as well as what you do when someone tries to edit the data in the view. Strictly speaking, a view cannot be edited and is 'read-only' — when you try to modify a field in the view, the controller needs to pick up the editing event, process it, and send it to the model; the model will then update the view if/when the value actually changes.
Что мы видим. Благодаря shouldComponentUpdate, мы можем обновлять или не обновлять визуальное представление View в браузере. Плюс у нас есть методы handler, которые navigating around the view, as well as what you do when someone tries to edit the data in the view. И те самые callback, которые есть почти у каждого виджета, через которые мы возвращаем данные в корневой виджет для изменения state.
А далее controller needs to pick up the editing event, process it, and send it to the model; the model will then update the view if/when the value actually changes. Какое совпадение слово в слово совпадает с тем, как реализованы изменения в React.
Идеология React для меня это по возможности stateless-компоненты, которые предсказуемы и их поведение ожидаемо. Плюс тесная интеграция с внутренним состоянием всего приложения через state корневого виджета позволяет буквально сериализовывать все состояние приложения в одну команду. Естественно тут большую роль начинают играть алгоритмы для копирования данных state, т.к. надо работать с immutable данными.