Не завидую тем фронтам, кто будет поддерживать код, структура которого задана нейронкой (ох, я бы ей не доверял строить базовый код )), когда придется вносить правки. Дизайнер будет разводить руками, мол, "зато мы сэкономили на тебе две недели"
Я думаю, на этот вопрос даст ответ только конкретный результат (и только для конкретного случая). Если по итогу проект необходимо сложен и достаточно прост, отказоустойчив и масштабируем - я бы сказал, что он написан хорошо. Мои критерии: 1) Если в моем проекте разобрался другой человек, задавая минимум вопросов, 2) если я решаю типовые задачи, часто переиспользуя существующий код, 3) как пример, если с бэка прилетают странные данные, и мой проект не падает, а вполне штатно диагностирует, что конкретно ему не нравится (и пишет мне руководство к действию, сэкономив мне время на отладку и поиск причин), 4) ну и соблюдены прочие мелочи в плане производительности - почему бы мне не считать себя нормальным кодером?
Есть одна китайская поговорка "Следи за тем что ты ешь, и у тебя изменится походка". Слепое следование регламентам делает найм хуже и приводит его то состояние в котором он сейчас - "такие правила". Кстати, впервые слышу про "правила" - занимающий должен задавать правила, т.к. его экспертное мнение решает, а не чье либо еще. Но если нет своего опыта - наверное, кроме следования "правилам" ничего не остается, чтоб выглядеть на видео встреч покладистым и "правильным" в глазах тех кто что-то "спустил сверху"
Я к тому и веду, что "двухчасовая душнилка" совершенно не обязательна после "начала разговора" - это говорит о том, что нет опыта выявлять спеца за 20 минут. Вот вся проблема современного найма.
То есть мы пришли к тому, что к стрессовому решению задачек "специально готовиться наверное надо". Таким образом, в очередной раз подтверждаем, что прохождение собеса - это отдельный навык, к которому надо готовиться и тренировать. Я категорически с этим не согласен, конечно, т.к. это не коррелирует со здравым смыслом ) человек должен идти вперёд, а не вечно готовиться к собесам - быть творцом, а не дрессированной обезьяной. Все же, что-то не так с современным наймом.
Могу рассказать про самый крутой собес в своей жизни в 2020-м. Парень, который его проводил сейчас работает в fb (инфраструктурная разработка), задолго до нашего сотрудничества - в yandex (помню, у него три любимых языка: js, py, и как вы думаете что ещё?.. perl)
Ну так вот задал он мне одну единственную задачку и дал открытую на своем ноуте ide без подсветки синтаксиса (это правда мелочь, не знаю зачем вспомнил). Задача простая с анаграммами, да были разговоры про js но без двухчасового вымораживания - через 20 минут мы с ним пили кофе на первом этаже; через пару дней оффер на 30К больше, чем я ожидал - и конец истории.
Выявить опыт можно, отслеживая ход мысли. И для этого просто надо пообщаться, задавая правильные вопросы, а не сидеть и смотреть на камеру собеседника и гадать, юзает он ии или нет
с 10-летним опытом не могут написать работающий код в реальном времени
Так вы каждый день по 4 собеса проводите, а я по 1-4 года в одной компании работаю, и ненавижу собесы, т.к это стресс ) плюс, задача может быть нетипичной для меня - и это двойной стресс. При этом в рабочем процессе, решая повседневные бизнес-задачи, я очень быстро пишу код (разумеется, после того как я в голове сформировал рабочее решение в спокойной обстановке). Все по-разному переносят стресс - но этот факт, конечно, никому из интервьюеров не интересен )
Я могу предложить начать с того чтоб не отвлекаться на мелочи - не просите включить камеру, обращайте больше внимания на предметную область (суть), а не на мелочи, поменьше внимания к собственной персоне интервьюера, больше внимания к сути вакансии и проф навыкам соискателя (т.к. именно это является важным, а не то как он на вас посмотрел, что он про вас не спросил и т.д.)
Похоже, мы вплотную подошли к проблеме: Когда появляется широкий выбор кандидатов (не просто большой, а офигенно большой) - hr теряет фокус и начинает руководствоваться субъективными критериями (проф навыки кандидатов уже отходят на второй план). Как это "пофиксить" - отдельная тема.
Самое удивительное для меня - в какой момент это стало неочевидным для самих интервьюеров? (вопрос риторический)
Вроде бы это технология установки из браузера (напомню для сохранения контекста). Каждый браузер может построить работу в оффлайне по-своему (придерживаясь стандартов, естесственно) - то есть нет необходимости для этого устанавливать мобильное приложение. Зачем для этого "магазин"?
пользователи инстинктивно доверяют ему меньше
Думаю, не меньше, чем самому браузеру, который они используют для просмотра веб-страниц
Я смотрел пару лет назад, тогда мне показалось, что инструмент сам по себе по сложности сильно превосходит задачи, которые он решает. Выглядит, конечно, как реактивный двигатель производства иных цивилизаций. Не то что бы $mol та штука, в которую можно быстро вкатиться с учётом того, что нужно освоить ЯП, если в этом изменений не было )) так что, боюсь, потребуется времени больше чем на что-либо другое (более очевидное).
В остальном, Дмитрий молодец, хорошая штука. К этому нужно делать что-то вроде обучающего модуля, чтоб проще было вкатиться
Кстати, да. Под реактивностью обычно хочется видеть как минимум Proxy-объект. Это несложно, но это должно быть абстрагировано от UI - отсюда следует, что это не проблема управления вкладками или прочим UI, а скорее, подписка на изменение состояния (и должно быть описано отдельно)
Это интересный эксперимент, но, кмк, для простого лендинга (или другого контента со статической разметкой). Работа построенная на мутациях DOM напрямую в растущем проекте ведёт к росту императивного кода и снижению уровня абстракции и его рассеиванию (а должно быть наоборот). Да, здесь работа сводится к работе с данными - это хорошо, но я подозреваю, отказавшись от React (как заявлено в заголовке), Вы должны будете прийти к его альтернативе как минимум т.к. обновление данных - это ещё не всё, также нужна возможность описывать поведение аппки, чтоб оставаться на высоком уровне абстракции.
Это да. Как мне кажется, в fsd есть одна хорошая фундаментальная идея - разбивать бизнес-логику на слои, но вокруг этого раздута "методология" с кучей вопросов и ответов, у многих создаётся ложное представление, что этот грамотный подход присущ исключительно fsd. Достаточно сместить фокус из fsd в сторону принципиального разделения БЛ на слои, каждый из которых имеет свою зону ответственности и может быть доработан в абстракции от других - и окажется, что архитектура может быть совершенно разной (я предпочитаю древовидную) без жёстких рамок "здесь папки создаём с такими файликами, там с другими" - в итоге окажется, что fsd это только один из вариантов (кмк, не самый лучший, чтоб на нем зацикливаться)
Как-то в одной крупной компании я был свидетелем обсуждения недовольства, почему пин-код клиента для входа в приложение хранится в локал-сторадж ("это немыслимо", "что скажут безопасники"...). Но как-то недалеко от релиза я слышу "ребят, давайте запустим уже через месяц, топ-менеджмент ждать не любит". И тут я все понял...
Не завидую тем фронтам, кто будет поддерживать код, структура которого задана нейронкой (ох, я бы ей не доверял строить базовый код )), когда придется вносить правки. Дизайнер будет разводить руками, мол, "зато мы сэкономили на тебе две недели"
Что ж, хотябы понятно почему не опенсорс
Я думаю, на этот вопрос даст ответ только конкретный результат (и только для конкретного случая). Если по итогу проект необходимо сложен и достаточно прост, отказоустойчив и масштабируем - я бы сказал, что он написан хорошо. Мои критерии: 1) Если в моем проекте разобрался другой человек, задавая минимум вопросов, 2) если я решаю типовые задачи, часто переиспользуя существующий код, 3) как пример, если с бэка прилетают странные данные, и мой проект не падает, а вполне штатно диагностирует, что конкретно ему не нравится (и пишет мне руководство к действию, сэкономив мне время на отладку и поиск причин), 4) ну и соблюдены прочие мелочи в плане производительности - почему бы мне не считать себя нормальным кодером?
Есть одна китайская поговорка "Следи за тем что ты ешь, и у тебя изменится походка". Слепое следование регламентам делает найм хуже и приводит его то состояние в котором он сейчас - "такие правила". Кстати, впервые слышу про "правила" - занимающий должен задавать правила, т.к. его экспертное мнение решает, а не чье либо еще. Но если нет своего опыта - наверное, кроме следования "правилам" ничего не остается, чтоб выглядеть на видео встреч покладистым и "правильным" в глазах тех кто что-то "спустил сверху"
Я к тому и веду, что "двухчасовая душнилка" совершенно не обязательна после "начала разговора" - это говорит о том, что нет опыта выявлять спеца за 20 минут. Вот вся проблема современного найма.
То есть мы пришли к тому, что к стрессовому решению задачек "специально готовиться наверное надо". Таким образом, в очередной раз подтверждаем, что прохождение собеса - это отдельный навык, к которому надо готовиться и тренировать. Я категорически с этим не согласен, конечно, т.к. это не коррелирует со здравым смыслом ) человек должен идти вперёд, а не вечно готовиться к собесам - быть творцом, а не дрессированной обезьяной. Все же, что-то не так с современным наймом.
Для остальных тоже есть выбор - эйджизм или пенсия? Что-то из этого наверняка подойдёт )
Могу рассказать про самый крутой собес в своей жизни в 2020-м. Парень, который его проводил сейчас работает в fb (инфраструктурная разработка), задолго до нашего сотрудничества - в yandex (помню, у него три любимых языка: js, py, и как вы думаете что ещё?.. perl)
Ну так вот задал он мне одну единственную задачку и дал открытую на своем ноуте ide без подсветки синтаксиса (это правда мелочь, не знаю зачем вспомнил). Задача простая с анаграммами, да были разговоры про js но без двухчасового вымораживания - через 20 минут мы с ним пили кофе на первом этаже; через пару дней оффер на 30К больше, чем я ожидал - и конец истории.
Выявить опыт можно, отслеживая ход мысли. И для этого просто надо пообщаться, задавая правильные вопросы, а не сидеть и смотреть на камеру собеседника и гадать, юзает он ии или нет
Так вы каждый день по 4 собеса проводите, а я по 1-4 года в одной компании работаю, и ненавижу собесы, т.к это стресс ) плюс, задача может быть нетипичной для меня - и это двойной стресс. При этом в рабочем процессе, решая повседневные бизнес-задачи, я очень быстро пишу код (разумеется, после того как я в голове сформировал рабочее решение в спокойной обстановке). Все по-разному переносят стресс - но этот факт, конечно, никому из интервьюеров не интересен )
Я могу предложить начать с того чтоб не отвлекаться на мелочи - не просите включить камеру, обращайте больше внимания на предметную область (суть), а не на мелочи, поменьше внимания к собственной персоне интервьюера, больше внимания к сути вакансии и проф навыкам соискателя (т.к. именно это является важным, а не то как он на вас посмотрел, что он про вас не спросил и т.д.)
Похоже, мы вплотную подошли к проблеме: Когда появляется широкий выбор кандидатов (не просто большой, а офигенно большой) - hr теряет фокус и начинает руководствоваться субъективными критериями (проф навыки кандидатов уже отходят на второй план). Как это "пофиксить" - отдельная тема.
Самое удивительное для меня - в какой момент это стало неочевидным для самих интервьюеров? (вопрос риторический)
Вроде бы это технология установки из браузера (напомню для сохранения контекста). Каждый браузер может построить работу в оффлайне по-своему (придерживаясь стандартов, естесственно) - то есть нет необходимости для этого устанавливать мобильное приложение. Зачем для этого "магазин"?
Думаю, не меньше, чем самому браузеру, который они используют для просмотра веб-страниц
Я смотрел пару лет назад, тогда мне показалось, что инструмент сам по себе по сложности сильно превосходит задачи, которые он решает. Выглядит, конечно, как реактивный двигатель производства иных цивилизаций. Не то что бы $mol та штука, в которую можно быстро вкатиться с учётом того, что нужно освоить ЯП, если в этом изменений не было )) так что, боюсь, потребуется времени больше чем на что-либо другое (более очевидное).
В остальном, Дмитрий молодец, хорошая штука. К этому нужно делать что-то вроде обучающего модуля, чтоб проще было вкатиться
Ну соррямба, atomic design system не прикрутил в этот простейший пример ) но ты молодец, что заметил
Конечно, можно вынести в конфиг настроек отдельно. Хотя, пожалуй, лучше решить это средствами чистого css - условно задать класс возможность есть.
Накидал свой пример https://habr.com/ru/articles/983268/
Кстати, да. Под реактивностью обычно хочется видеть как минимум Proxy-объект. Это несложно, но это должно быть абстрагировано от UI - отсюда следует, что это не проблема управления вкладками или прочим UI, а скорее, подписка на изменение состояния (и должно быть описано отдельно)
Это интересный эксперимент, но, кмк, для простого лендинга (или другого контента со статической разметкой). Работа построенная на мутациях DOM напрямую в растущем проекте ведёт к росту императивного кода и снижению уровня абстракции и его рассеиванию (а должно быть наоборот). Да, здесь работа сводится к работе с данными - это хорошо, но я подозреваю, отказавшись от React (как заявлено в заголовке), Вы должны будете прийти к его альтернативе как минимум т.к. обновление данных - это ещё не всё, также нужна возможность описывать поведение аппки, чтоб оставаться на высоком уровне абстракции.
Это да. Как мне кажется, в fsd есть одна хорошая фундаментальная идея - разбивать бизнес-логику на слои, но вокруг этого раздута "методология" с кучей вопросов и ответов, у многих создаётся ложное представление, что этот грамотный подход присущ исключительно fsd. Достаточно сместить фокус из fsd в сторону принципиального разделения БЛ на слои, каждый из которых имеет свою зону ответственности и может быть доработан в абстракции от других - и окажется, что архитектура может быть совершенно разной (я предпочитаю древовидную) без жёстких рамок "здесь папки создаём с такими файликами, там с другими" - в итоге окажется, что fsd это только один из вариантов (кмк, не самый лучший, чтоб на нем зацикливаться)
Как-то в одной крупной компании я был свидетелем обсуждения недовольства, почему пин-код клиента для входа в приложение хранится в локал-сторадж ("это немыслимо", "что скажут безопасники"...). Но как-то недалеко от релиза я слышу "ребят, давайте запустим уже через месяц, топ-менеджмент ждать не любит". И тут я все понял...