Еще одно преимущество использования приемников-указателей — отсутствие необходимости копировать значение при каждом вызове метода, что существенно экономит ресурсы при работе с большими структурами.
Полгода назад или около того была статься от Яндекса на Хабре, да и на англоязычных источниках читал, что копировать структуру, даже большую, дешевле, чем передавать везде ссылки и вычитывать, а можно ли уже "дропнуть" ее, тк там надо в кучу лазить много раз и производить попутную работу
Вот вы знаете, для тех, кто не работал с джавой десятилетиями (сужу по себе и не только), это одна из причин, почему выбрал го, в итоге, для сайд проекта.
Не смотря на то, что мне нравится Котлин и он мне интуитивно понятен и приятен, на Ktor+ jooq сделал тестово сервис небольшой, все же свобода выбора той же ИДЕ и ресурсов перевесил не в пользу этой экосистемы. Хотя язык мне по своей сути очень зашёл.
Кстати, материалов чисто для бэкенда на мой взгляд меньше, чем на го, но это может и субъективно
Ну и, если честно, смущает, что java и kotlin такие конкурирующие языки, то есть кому-то из них надо доверить свой ценный ресурс - время
Если полтора года, то это уже вообще другой nuxt. Они как-то уж вперёд паровоза прут.
Честно, другое не пробовал, но если бы понадобился ssr, то nuxt3 стал бы первым вариантом. Только, надо сразу все их автоимпорты и примочки отключать, имхо.
Так нет абсолютно никакой разницы. Фрейморк - это просто объединение готовых механизмов по своей сути. Дальше все стандартно со стороны работы браузера.
Дело в том, что сути в таком "ответе" очень мало, фактически глубины знаний здесь для тех. собеса маловато, особенно для мидла. Более того, не так важно, в каком кеше хранится таблица для DNS. Для фронтенд разработчика куда важнее этап общения между сервером, когда HTML начинает парситься браузером и как часто и по каким причинам браузер производит отрисовку.
Какой механизм задействован при парсинге. Как браузер понимает, что это конкретный элемент. Почему бразуер не продолжает парсить html, пока не обработает JS. Что происходит при обработке JS. И куча куча нюансов, по которым можно понимать глубину знаний и понимания, что на самом деле происходит.
Все таки, техническое интервью оно на то и техническое. А вот такая статья - это популистский материал.
Я думаю, что вместо очередного краткого пересказа и без того простой статьи с MDN лучше было чутка подробнее рассказать про какой-нибудь сложный и интересный кейс в этом всем процессе.
Такое поверхностное описание - это даже не уровень джуна, если честно. Если говорить про собеседования, с которых вы начали.
Рассмотрим именно загрузку статических страниц, хотя для фреймворков процесс будет немного сложнее.
Да, можно ещё бандлеры не изучать, лид там как-нибудь что-нибудь соберёт, и можно 2 кнопки ждать install/run..
Конечно, в идеале должен быть человек, который возьмёт на себя девопс, настроит скрипты и тд
Но ждать человека, а если он ещё и в отпуске, чтобы поправить/добавить/убрать какую нибудь мелочь, например, уже не очень приятно и удобно, тк билд надо собрать уже сейчас
И, имхо, понимать что происходит в разработке на разных уровнях - именно то, что подразумевает работа инженера
К сожалению, автор сам не до конца понимает solid и подмешивает одно к другому.
При этом игнорирует или не понимает принцип черного ящика, инкапсуляции и тд.
А так же не до конца понимает, что шаблоны созданы, чтобы иметь возможность динамически подмешивать часть (или даже объёмную часть) в шаблон, которая или что-то отрисует в ожидаемом месте или даже чтото сделает в не рамках логики исходного компонента.
При том упоминается бизнес логика, которой на самом деле нет..
На производстве есть конструктор, который должен обеспечить 3d макет + адекватные чертежи. А инженер + слесарь/токарь etc это должно реализовать. Или указать на возможные нюансы. И совместно придти к чему-то хорошему.
Чем разрабокта хуже? Я повсеместно топлю за инженерный подход к делу, где люди, в том числе и дизайнер, !должны! понимать, что и для кого делают. Иначе, какой в это смысл? Ну кроме зарабатывания деньжат до тех времен, пока не сменят этот штат, потому что продукт не жизнеспособный
А трогали, потому что позаботились о пользователях, а не склепали стандартный интерфейс и забили
А почему именно производство только? Я вот уже до невозможности устал бороться с манией у дизайнера и руководства пихать шрифты 12px. Не говоря о том, каких там только размеров нет. Мелкий 12px блекло-серый цвет - прям уххх! Кому такое будет удобно? Наверно, только дизайнеру, у которого карточка на весь экран, когда он "рисует". И руководство, у которого х1.5 увеличение на ноуте... Накипело
Такие ошибки должны падать во внутренние логи и быстро решаться. Отдавать полный стак никто не будет в прод-сборке, от части по той причине, которая не нравится некоторым людям, а именно - это лишняя информация, которая никак не поможет пользователю решить проблему с веб-приложением, ну если в базе что-то не так, то ты как фронт не мучай.. а не такая инфа просто может напрячь среднестатистического пользователя. + Руководство не обрадуется светить гигантским стектрейсов на пару кб, если смотреть на spring, н-р
С андроидом гибкости, возможно, побольше
Не говорю, что это все хорошо, тк сам как самому всегда интересно глянуть, что там на самом деле, но даже знание тут мало что даёт, на самом деле с точки зрения веб-поиложения
Если требуется передать свойство, которое ещё и надо иметь возможность изменить, имхо, лучше его обернуть в ридонли и рядом прокинуть метод для изменения этого самого свойства
Удивительно, что на две бытовых строчки кода такая объемная статься вышла. И название такое, что думал что-то необычное увидеть
Но совсем уж начинающим может пригодиться, жаль, что такую статью через Гугл не найти, слишком сложное для этого название. На вашем месте, я бы упростил
Кому интересно, какие плюсы у этого подхода:
Если смотреть фронтенд - не надо импортить везде как enum, и что ещё хуже добавлять в контекст компонента для того, чтобы он попал в рендер (привет vue2)
Удобно описать валидатор для конечной точки в цепочке компонентов (функций). В цепочке проверяем тип (и удобно указываем значения), в конце проверяем, что никто не навлевал на требуемый тип, ибо ts не гарантия :)
Полгода назад или около того была статься от Яндекса на Хабре, да и на англоязычных источниках читал, что копировать структуру, даже большую, дешевле, чем передавать везде ссылки и вычитывать, а можно ли уже "дропнуть" ее, тк там надо в кучу лазить много раз и производить попутную работу
Вот вы знаете, для тех, кто не работал с джавой десятилетиями (сужу по себе и не только), это одна из причин, почему выбрал го, в итоге, для сайд проекта.
Не смотря на то, что мне нравится Котлин и он мне интуитивно понятен и приятен, на Ktor+ jooq сделал тестово сервис небольшой, все же свобода выбора той же ИДЕ и ресурсов перевесил не в пользу этой экосистемы. Хотя язык мне по своей сути очень зашёл.
Кстати, материалов чисто для бэкенда на мой взгляд меньше, чем на го, но это может и субъективно
Ну и, если честно, смущает, что java и kotlin такие конкурирующие языки, то есть кому-то из них надо доверить свой ценный ресурс - время
Получается, можно было бы сравнить с виртуальными потоками, если не ошибаюсь
Или просто потом отключат бесплатную часть..
import zfg ...Придумал вам маркетинговый лозунг:
"ZFGачь переменную, чтобы завелось"
🫣😁
Завезли бы еще поддержку работы с гитом как в vscode или idea, было бы очень здорово
Если полтора года, то это уже вообще другой nuxt. Они как-то уж вперёд паровоза прут.
Честно, другое не пробовал, но если бы понадобился ssr, то nuxt3 стал бы первым вариантом. Только, надо сразу все их автоимпорты и примочки отключать, имхо.
А как вам СТО, который велел придти к 100% покрытию и TDD?
Так нет абсолютно никакой разницы. Фрейморк - это просто объединение готовых механизмов по своей сути. Дальше все стандартно со стороны работы браузера.
Дело в том, что сути в таком "ответе" очень мало, фактически глубины знаний здесь для тех. собеса маловато, особенно для мидла. Более того, не так важно, в каком кеше хранится таблица для DNS. Для фронтенд разработчика куда важнее этап общения между сервером, когда HTML начинает парситься браузером и как часто и по каким причинам браузер производит отрисовку.
Какой механизм задействован при парсинге. Как браузер понимает, что это конкретный элемент. Почему бразуер не продолжает парсить html, пока не обработает JS. Что происходит при обработке JS. И куча куча нюансов, по которым можно понимать глубину знаний и понимания, что на самом деле происходит.
Все таки, техническое интервью оно на то и техническое. А вот такая статья - это популистский материал.
Я думаю, что вместо очередного краткого пересказа и без того простой статьи с MDN лучше было чутка подробнее рассказать про какой-нибудь сложный и интересный кейс в этом всем процессе.
Такое поверхностное описание - это даже не уровень джуна, если честно. Если говорить про собеседования, с которых вы начали.
И чем же?
Будет предустановленна в системе
Да, можно ещё бандлеры не изучать, лид там как-нибудь что-нибудь соберёт, и можно 2 кнопки ждать install/run..
Конечно, в идеале должен быть человек, который возьмёт на себя девопс, настроит скрипты и тд
Но ждать человека, а если он ещё и в отпуске, чтобы поправить/добавить/убрать какую нибудь мелочь, например, уже не очень приятно и удобно, тк билд надо собрать уже сейчас
И, имхо, понимать что происходит в разработке на разных уровнях - именно то, что подразумевает работа инженера
К сожалению, автор сам не до конца понимает solid и подмешивает одно к другому.
При этом игнорирует или не понимает принцип черного ящика, инкапсуляции и тд.
А так же не до конца понимает, что шаблоны созданы, чтобы иметь возможность динамически подмешивать часть (или даже объёмную часть) в шаблон, которая или что-то отрисует в ожидаемом месте или даже чтото сделает в не рамках логики исходного компонента.
При том упоминается бизнес логика, которой на самом деле нет..
На производстве есть конструктор, который должен обеспечить 3d макет + адекватные чертежи. А инженер + слесарь/токарь etc это должно реализовать. Или указать на возможные нюансы. И совместно придти к чему-то хорошему.
Чем разрабокта хуже? Я повсеместно топлю за инженерный подход к делу, где люди, в том числе и дизайнер, !должны! понимать, что и для кого делают. Иначе, какой в это смысл? Ну кроме зарабатывания деньжат до тех времен, пока не сменят этот штат, потому что продукт не жизнеспособный
А трогали, потому что позаботились о пользователях, а не склепали стандартный интерфейс и забили
А почему именно производство только?
Я вот уже до невозможности устал бороться с манией у дизайнера и руководства пихать шрифты 12px. Не говоря о том, каких там только размеров нет.
Мелкий 12px блекло-серый цвет - прям уххх! Кому такое будет удобно? Наверно, только дизайнеру, у которого карточка на весь экран, когда он "рисует". И руководство, у которого х1.5 увеличение на ноуте...
Накипело
Ну вот, +1 случай к 500.
Такие ошибки должны падать во внутренние логи и быстро решаться. Отдавать полный стак никто не будет в прод-сборке, от части по той причине, которая не нравится некоторым людям, а именно - это лишняя информация, которая никак не поможет пользователю решить проблему с веб-приложением, ну если в базе что-то не так, то ты как фронт не мучай.. а не такая инфа просто может напрячь среднестатистического пользователя. + Руководство не обрадуется светить гигантским стектрейсов на пару кб, если смотреть на spring, н-р
С андроидом гибкости, возможно, побольше
Не говорю, что это все хорошо, тк сам как самому всегда интересно глянуть, что там на самом деле, но даже знание тут мало что даёт, на самом деле с точки зрения веб-поиложения
А точно ли фронтенд? Или все же бэк что-то не обработал при изменении чего-то в базе и прислал 500?
К сожалению, фронтенд не может описать каждую ошибку самостоятельно. Задача фронтенда отобразить то, что ему передали.
Если требуется передать свойство, которое ещё и надо иметь возможность изменить, имхо, лучше его обернуть в ридонли и рядом прокинуть метод для изменения этого самого свойства
Интересная формулировка.
То есть, в целом, они не ошибаются только, когда вы с ними согласны? :)
Удивительно, что на две бытовых строчки кода такая объемная статься вышла. И название такое, что думал что-то необычное увидеть
Но совсем уж начинающим может пригодиться, жаль, что такую статью через Гугл не найти, слишком сложное для этого название. На вашем месте, я бы упростил
Кому интересно, какие плюсы у этого подхода:
Если смотреть фронтенд - не надо импортить везде как enum, и что ещё хуже добавлять в контекст компонента для того, чтобы он попал в рендер (привет vue2)
Удобно описать валидатор для конечной точки в цепочке компонентов (функций). В цепочке проверяем тип (и удобно указываем значения), в конце проверяем, что никто не навлевал на требуемый тип, ибо ts не гарантия :)