https://habr.com/ru/articles/778236/

#spa #google #ssr #article #seo

Как надо проводить интервью на разработчика ПО

Интересная статья сотрудника Google Wil Wen, в обязанности которого входило интервьюирование соискателей, и которых он провел более двухсот.

В большинстве случаев он давал всего одну задачу, причем давал и тем, кто искал позицию стажера, и на позицию L5 (Senior SWE). То, как испытуемый решал её, определяло его уровень.

Вот эта задача: дан некий массив чисел, например:
a = [ 3, 4, 6, 9, 10, 12, 14, 15, 17, 19, 21 ];
Надо определить функцию f(a, x), которая возвращала бы ближайшее к x наименьшее число массива или -1 в случае ошибки.
То есть, например: f(a, 12) = 12, f(a, 13) = 12

Нужно было написать код, времени давалось около часа. Рабочее решение состоит из примерно 30 строк кода.

Проверяющий смотрел как на техническую сторону - определил ли испытуемый все необходимые тест-кейсы, использовал ли простой перебор или двоичный поиск, знал ли о возможности выхода за пределы Int.MAX. и т.п.

Так и на другие "сигналы" - какие уточняющие вопросы он задавал, как размышлял, какие названия давал переменным и как форматировал код, в каком стиле и темпе писал код и дебажил его, как реагировал на ошибки.

По словам Wil Wen, принятое им по результатам такого теста решение в будущем почти всегда подтверждалось квалификацией человека.

#article #job

Статья на VueSchool о том, когда стоит использовать provide/inject

Варианты использования функций provide и inject:

- Настройки темы или конфигурации: Вы можете предоставить глобальные настройки, темы или параметры конфигурации на корневом уровне вашего приложения Vue.js и внедрить их в любой компонент, которому они нужны.

- Данные аутентификации: Предоставляйте информацию об аутентификации пользователя, например данные пользователя или токены аутентификации, компонентам, которым они необходимы, не передавая их через пропсы.

- Интернационализация (i18n): Храните данные перевода на корневом уровне и внедряйте их в компоненты, которым требуется отображать текст на разных языках.

- Тесно связанные компоненты: Например, <AccordianPanel>, который всегда появляется только внутри слота компонента <Accordian>. Вы можете инжектировать общие данные, к которым вы всегда хотите иметь доступ, без необходимости передавать их в качестве пропсов.


Лучшие практики и соображения

При использовании provide и inject необходимо помнить о нескольких лучших практиках:

- Избегайте чрезмерного использования: Хотя provide и inject могут быть очень мощными, не стоит ими злоупотреблять. Оставьте их для случаев, когда вам действительно нужно поделиться данными между компонентами, не создавая тесной связи между ними.

- Четкая документация: Документируйте данные, которые вы провайдите и инжектируете, чтобы разработчикам было легко понять, как взаимодействуют компоненты. Их также можно типизировать, - подробности в официальной документации.

- Рассмотрите возможность Prop Drilling: Prop drilling обычно является антипаттерном, но в некоторых случаях передача данных через пропсы может быть более простым и прозрачным подходом. Оцените, являются ли provide и inject лучшим решением для вашего конкретного сценария.

#provide #article #tip

Artem Zakharchenko, автор библиотеки для тестирования MSW с 15К звезд на GitHub, поделился мыслями о Test Driven Development:

TDD - это неправильная практика. Она всегда была неправильной. Она неправильна по определению. Ее главная заслуга - поощрение тестирования, но на этом все и заканчивается.

TDD подразумевает написание тестов до написания кода. Так что же в этом неправильного? Вы пишете тесты, чтобы описать намерения, стоящие за системой - как вы ожидаете, что она будет себя вести. TDD в значительной степени подразумевает, что вы должны знать, как ведет себя система, еще до ее реализации. Вы должны знать, что вы делаете.

В большинстве случаев вы этого не знаете. Все разработчики, которых я знаю, не знают этого заранее. Я не знаю этого заранее. На самом деле, я могу потратить несколько дней на эксперименты, написание MVP, пока не начну немного понимать, какими должны быть части моей системы и чего я от них ожидаю.

Я не считаю TDD жизнеспособным подходом в быстро развивающихся системах, таких как веб. Он может иметь гораздо больше смысла при написании систематического программного обеспечения, в котором очень мало что меняется от проекта к проекту. Это полная противоположность тому, что вы пишете в Интернете.

Негативный аспект TDD заключается в том, что я видел, как команды разочаровываются, если им не удается следовать ему. И тогда они отказываются от всей идеи тестирования, поскольку TDD так широко ассоциируется с ним. Вместо того чтобы поощрять людей к тестированию и показывать им, что тестирование программного обеспечения может быть интересным, эта практика запирает их в педантичных ограничениях, которым не может следовать ни один инженер.

Я не придерживаюсь TDD. Это не значит, что я не пишу тесты. Я пишу много тестов. Я занимаюсь разработкой прототипов, итераций и тестов.

Прототип. Я даю своим идеям простор и позволяю им дышать, не слишком заботясь о тестировании на первых порах. Я экспериментирую, меняю вещи, ломаю вещи, ставлю себя на место пользователя и разрабатываю API, поведение и ожидания. Как я уже сказал, это может занять некоторое время.

Итерация. Я трачу это время на то, чтобы убедиться, что моя система имеет смысл и удовлетворяет предъявляемым к ней требованиям (которые сами по себе могут развиваться и менять то, зачем я это делаю).

Тестировать. Наконец, я пишу тесты. Это стало неотъемлемой частью моего рабочего процесса. Я не могу представить себе, что не пишу тесты.

Конечно, бывают исключения. Если я пишу простую функцию ввода-вывода, то не нужно тратить день на то, чтобы понять, что она делает, потому что это все, что она будет делать. Я могу написать для нее несколько модульных тестов с самого начала. Но большинство моих (и, я уверен, ваших тоже) работ - это не простые функции. Это сложная логика, на отладку которой требуется время. Если я буду неукоснительно следовать TDD, я буду тратить время на написание тестов, которые в итоге выброшу. Это бесполезно и не поможет мне обрести уверенность в том, что я создаю.

Не отчаивайтесь. Применяйте те практики, которые работают для вас (даже если это TDD, лишь бы вы не лгали себе!). Главное, что тестирование имеет значение. Оно всегда имело значение. Разработчики тестируют программное обеспечение с 80-х годов, я полагаю. Вы тоже должны! Я сделаю все возможное, чтобы показать вам, что тестирование может быть доступным и увлекательным.

#testing #tdd #article

Перевел статью Artem Zakharchenko "Темная сторона Open Source"

#opensource #article #habr

Тем временем работа над Rolldown идет своим чередом.

По замерам билд с sourcemaps на Rolldown идёт уже быстрее, чем на esbuild

Также перевел и опубликовал интересный твит создателя FormKit Джастина Шрёдера по теме. Кстати, это первая статья о Rolldown на Хабре.

#esbuild #rolldown #vite #article

Неплохая статья о "Cобытиях жизненного цикла компонента"

#article

Хорошая статья о том, что такое движки и рантаймы JavaScript

#js #runtime #article

Описал, как с помощью AI можно быстро и качественно сделать интернационализацию сайт

На этом примере видно, как еще можно использовать AI кроме автокомплита.

Посвящается Денису Чернову

#ai #i18n #article

Неплохая статья о Vapor

#article #vapor

Написал статью "Обзор различных методов работы с реактивным стейтом во Vue"

Переделанная вот эта. Исправлены фундаментальные ошибки (автор не понимает, что такое composable функция) и некоторые другие недочеты

Внизу статьи опрос, просьба проголосовать.

Также размещено на Vue-FAQ

#reactivity #pinia #eventbus #article

Написал статью про Model Context Protocol

Грубо говоря, это попытка выработать стандартный API для соединения LLM и инструментов - любых приложений, делающих что-то специфичное.

На двух последних проектах окунулся в работу с AI и эта штука (MCP) очень сильно может помочь в разработке приложений, использующих LLM. Чтобы не выклянчивать у чатбота что-то в диалоге, а использовать его для управления специализированными инструментами и получать на порядок более качественный результат.

#ai #article

Очередной бессмысленный и беспощадный лонгрид: React vs Vue – подробное сравнение и перспективы

Комментировать не буду

#react #article

Ссылка была на англоязычный vue-faq.org на Реддите

На этом канале 900 человек, из них пусть половина вьюшников, а статьи по Vue на том же Хабре выходят раз в месяц.

Писать надо не из тщеславия, а потому, что при создании статьи, понимание ее материала выходит на новый уровень.

Аспирантов заставляют преподавать не из-за того, что мало преподавателей, а потому, что подготавливая материал, они сами узнают его намного лучше. Это как включить у AI режим thinking - "дай ответ и покритикуй его"

Если хотите развиваться как программист или просто человек, надо писать. Даже если будут ошибки, это пойдет только на пользу и развитие.

#article #learning