Реальные проекты бывают очень разные, и в основном то как пишется код в реальном проекте зависит от того что это за проект.
Нет идеального способа декомпозировать задачи, поддерживать стиль, обрабатывать ошибки, именовать сущности, документировать, и так далее, так далее, так далее. Процентов 80, по моим личным ощущениям, все в специфике конкретного проекта, лишь на оставшиеся 20 некие прописные истины вроде «функция не должна занимать больше пол-экрана» и «весь пользовательский ввод должен санироваться» и «не должно быть больше трех вложенных друг в друга циклов».
На собеседовании проекта нет, соответственно нет всех этих 80% требований, который на всех предыдущих проектах в которых человек участвовал, могли радикально различаться.
А требовать ловить все возможные null pointer'ы в функции из пяти строчек, про которую автор точно знает, что ни в какой продакшен она не пойдет, и я знаю что он это знает, это странно.
Вопрос вида «Этот код предполагает уйти в прод, какие вы видите в нем проблемы? Выпустите вы, лично, его в прод, или нет?» я лучше задам отдельно.
It depends. Скажем так, на вопрос об оптимальном способе развернуть строку я бы ждал уточняющего вопроса «можно ли использовать Array.reverse?». И дал бы на него утвердительный ответ, скорее всего.
Если бы все таки дошло до разворачивания строки вручную, и человек начал бы писать что-то подобное, многое зависило бы от того насколько этот кадавр работает.
Если он не работает — претендент амбициозен, но переоценивает свои силы, можно брать на позицию джуна, если есть кому плотно за ним присматривать.
Если работает — либо он уже писал именно это в последние пару дней, либо мне попался очень головастый чувак. Пусть и оторванный от действительности. Возможно у меня есть задачи именно для него, тогда он мне ценен. В любом случае, даже если мне он не подходит, я приложу все усилия чтобы донести до него истинную причину отсутствия оффера.
Я, естественно, эту дичь писал, отлаживая ее в браузерной консоли по кускам.
В 99% случаев не только не пропустил бы, но еще и устроил бы разъяснительную беседу насчет поддерживаемости кода.
Оставшийся 1% приходится, в основном, на случаи когда разворачивание строки и есть весь проект, не имеющий, к тому же, коммерческой ценности.
Но поскольку с самого начала речь идет о задачке для собеседований, я полагаю что принципы промышленного программирования можно пока оставить в стороне.
Я как потомственный старпер и пескосып нечеловечески страдаю на утверждении, что оптимальным способом развернуть стоку является применение к ней функции reverse. Пусть даже и от массива, а не от строки.
В вашей крови опасно низкая концентрация хардкора, коллеги.
(хардкор ниже умеет й и ё, но ломается на эмоджах, как старпер этим даже немножечко горжусь)
Собственно, не жил в США, но беглое гугление выдает сайты вроде www.usatrace.com, где данные считающиеся законами РФ персональными и не разглашаемыми без явочного согласия их объкта выдаются совершенно легально по запросу.
В США нету GDPR.
потенциально можно докопаться до последовательности, идентификация происходит вместе с аутентификацией, а отделить их друг от дружки можно, заменив, скажем, ресторан на клуб а представление на флаер, по которому можно аутентифицироваться не идентифицируясь
но учитывая что это весьма спорная экзотика, иллюстрация с рестораном очень даже
уволоку для будущих разъяснений, с вашего позволения
Да, спасибо, сам я это сформулировать не осилил.
OAuth авторизует приложение и аутентифицирует клиентское приложение, OpenID Connect авторизует пользователя для приложения.
Я затрудняюсь, на самом деле, четко сказать что за чем стоит, описывая происходящее в терминах идентификации, аутентификации и авторизации. Слишком абстрактные понятия, иногда происходит и то и другое сразу, а иногда что-то одно внутри чего-то другого.
С аутентификацией и идентификацией проблема в том, что способы аутентификации без идентификации весьма редки. Watermarking возможно можно отнести к одному из них:
В любом случае, с идентификацией на мой взгляд несколько проще, ее и с теми что на «а» не спутаешь, и само ее название дает неплохую интуицию насчет того что это.
Даже в спецификации OAuth 2.0 написано, что это протокол авторизации, но я боюсь что это продолжение все той же путаницы аутентификации с авторизацией, даже спеки могут стать ее жертвами.
OpenID Connect по спецификации вообще слой идентификации поверх OAuth 2.0. Но тут, понятно, писать что это протокол авторизации поверх другого протокола, который тоже описан как протокол авторизации, было бы странно.
Снова к описанию из вики:
> Authorization is the function of specifying access rights/privileges to resources related to information security and computer security in general and to access control in particular.[1] More formally, «to authorize» is to define an access policy.
Пользовательские роли, описывающие его access rights/privileges оказываются как раз среди клеймов в JWT, то есть в OpenID Connect.
Я понимаю что спорить с официальными спеками довольно спорное развлечение, но тут другого варианта не вижу.
Собственно, не только автор путает термины, путаница с терминами начинается с самого их определения, взять википедию, например.
> Authentication is the act of confirming the truth of an attribute of a single piece of data claimed true by an entity.
Описание, мягко говоря, непростое для понимания.
Дальше с этим пытаются бороться, поясняя:
> In contrast with identification, which refers to the act of stating or otherwise indicating a claim purportedly attesting to a person or thing's identity, authentication is the process of actually confirming that identity.
То есть аутентификация — это не идентификация пользователя, мы не определяем кто он конкретно, но подтверждаем что он тот кем себя назвал.
Это в общем случае. А в случае, когда пользователь себя аутентифицирует парой логин\пароль мы лишь подтверждаем их валидность, не более.
> It might involve confirming the identity of a person by validating their identity documents, verifying the authenticity of a website with a digital certificate,[1] determining the age of an artifact by carbon dating, or ensuring that a product is what its packaging and labeling claim to be. In other words, authentication often involves verifying the validity of at least one form of identification.
То есть, в случае с парой логин\пароль мы ищем информацию о пользователе по введенному им логину, фактически — его идентифицируем. Но идентификация не обязательна для аутентификации в принципе, аутентификация — принятие решения о том пущать или не пущать, но не о том кого пущать.
И да, везде про аутентификацию написано длинно, сложно и на нее старательно пытаются навесить функции авторизации и идентификации ей не свойственные. Из-за чего и начинается путаница.
Отмечу, что такие машинки, будучи отдельными от любых визуальных компонент презентерами, отлично тестируются.
Это, возможно, самый хорошо тестируемый код из всех.
Строго говоря, автоматизируются, и даже двумя способами. Для интеграционного тестирования GUI есть сторонние решения вроде Селениума, а для тестирования логики можно и модульное применять.
Так ведь никто и не запрещает покупать. Это продажу предлагается регулировать.
Многие продавцы вводят покупателей в заблуждение, и чем товар бюджетней тем наглее ложь. Но где-то должна быть граница, нельзя продавать телефоны которые не включаются, машины которые не заводятся, и водку на метиловом спирту. Вопрос в том, переходит ли эту границу такая maleware, или все таки болтается по эту сторону.
задача вроде та же — сравнение с образцом, только по железной части возможностей побольше
и интерес китайцев к распознаванию лиц, я уверен, во многом связан с появлением «разблокировки по лицу» в большинстве последних китайских смартфонов
Отделение представления от функций — частный случай SRP, конечно же. Сложность с SRP, как с любым общим, глобальным принципом — в том что от его формулировки до применения на практике нужно проделать большую работу, очень большую, и здравый смысл, и весь накопленный опыт в дело пойдут, и чужой опыт тоже пригодится.
при этом отвечает
Нет идеального способа декомпозировать задачи, поддерживать стиль, обрабатывать ошибки, именовать сущности, документировать, и так далее, так далее, так далее. Процентов 80, по моим личным ощущениям, все в специфике конкретного проекта, лишь на оставшиеся 20 некие прописные истины вроде «функция не должна занимать больше пол-экрана» и «весь пользовательский ввод должен санироваться» и «не должно быть больше трех вложенных друг в друга циклов».
На собеседовании проекта нет, соответственно нет всех этих 80% требований, который на всех предыдущих проектах в которых человек участвовал, могли радикально различаться.
А требовать ловить все возможные null pointer'ы в функции из пяти строчек, про которую автор точно знает, что ни в какой продакшен она не пойдет, и я знаю что он это знает, это странно.
Вопрос вида «Этот код предполагает уйти в прод, какие вы видите в нем проблемы? Выпустите вы, лично, его в прод, или нет?» я лучше задам отдельно.
Если бы все таки дошло до разворачивания строки вручную, и человек начал бы писать что-то подобное, многое зависило бы от того насколько этот кадавр работает.
Если он не работает — претендент амбициозен, но переоценивает свои силы, можно брать на позицию джуна, если есть кому плотно за ним присматривать.
Если работает — либо он уже писал именно это в последние пару дней, либо мне попался очень головастый чувак. Пусть и оторванный от действительности. Возможно у меня есть задачи именно для него, тогда он мне ценен. В любом случае, даже если мне он не подходит, я приложу все усилия чтобы донести до него истинную причину отсутствия оффера.
Я, естественно, эту дичь писал, отлаживая ее в браузерной консоли по кускам.
Оставшийся 1% приходится, в основном, на случаи когда разворачивание строки и есть весь проект, не имеющий, к тому же, коммерческой ценности.
Но поскольку с самого начала речь идет о задачке для собеседований, я полагаю что принципы промышленного программирования можно пока оставить в стороне.
В вашей крови опасно низкая концентрация хардкора, коллеги.
(хардкор ниже умеет й и ё, но ломается на эмоджах, как старпер этим даже немножечко горжусь)
дергать:
В США нету GDPR.
потенциально можно докопаться до последовательности, идентификация происходит вместе с аутентификацией, а отделить их друг от дружки можно, заменив, скажем, ресторан на клуб а представление на флаер, по которому можно аутентифицироваться не идентифицируясь
но учитывая что это весьма спорная экзотика, иллюстрация с рестораном очень даже
уволоку для будущих разъяснений, с вашего позволения
OAuth авторизует приложение и аутентифицирует клиентское приложение, OpenID Connect авторизует пользователя для приложения.
С аутентификацией и идентификацией проблема в том, что способы аутентификации без идентификации весьма редки. Watermarking возможно можно отнести к одному из них:
en.wikipedia.org/wiki/Category:Watermarking
В любом случае, с идентификацией на мой взгляд несколько проще, ее и с теми что на «а» не спутаешь, и само ее название дает неплохую интуицию насчет того что это.
OpenID Connect по спецификации вообще слой идентификации поверх OAuth 2.0. Но тут, понятно, писать что это протокол авторизации поверх другого протокола, который тоже описан как протокол авторизации, было бы странно.
Снова к описанию из вики:
> Authorization is the function of specifying access rights/privileges to resources related to information security and computer security in general and to access control in particular.[1] More formally, «to authorize» is to define an access policy.
Пользовательские роли, описывающие его access rights/privileges оказываются как раз среди клеймов в JWT, то есть в OpenID Connect.
Я понимаю что спорить с официальными спеками довольно спорное развлечение, но тут другого варианта не вижу.
> Authentication is the act of confirming the truth of an attribute of a single piece of data claimed true by an entity.
Описание, мягко говоря, непростое для понимания.
Дальше с этим пытаются бороться, поясняя:
> In contrast with identification, which refers to the act of stating or otherwise indicating a claim purportedly attesting to a person or thing's identity, authentication is the process of actually confirming that identity.
То есть аутентификация — это не идентификация пользователя, мы не определяем кто он конкретно, но подтверждаем что он тот кем себя назвал.
Это в общем случае. А в случае, когда пользователь себя аутентифицирует парой логин\пароль мы лишь подтверждаем их валидность, не более.
> It might involve confirming the identity of a person by validating their identity documents, verifying the authenticity of a website with a digital certificate,[1] determining the age of an artifact by carbon dating, or ensuring that a product is what its packaging and labeling claim to be. In other words, authentication often involves verifying the validity of at least one form of identification.
То есть, в случае с парой логин\пароль мы ищем информацию о пользователе по введенному им логину, фактически — его идентифицируем. Но идентификация не обязательна для аутентификации в принципе, аутентификация — принятие решения о том пущать или не пущать, но не о том кого пущать.
И да, везде про аутентификацию написано длинно, сложно и на нее старательно пытаются навесить функции авторизации и идентификации ей не свойственные. Из-за чего и начинается путаница.
Это, возможно, самый хорошо тестируемый код из всех.
Многие продавцы вводят покупателей в заблуждение, и чем товар бюджетней тем наглее ложь. Но где-то должна быть граница, нельзя продавать телефоны которые не включаются, машины которые не заводятся, и водку на метиловом спирту. Вопрос в том, переходит ли эту границу такая maleware, или все таки болтается по эту сторону.
и интерес китайцев к распознаванию лиц, я уверен, во многом связан с появлением «разблокировки по лицу» в большинстве последних китайских смартфонов
Единственная странность — нет ни единого упоминания известной фруктовой компании.
Работает так не компилятор, а сам код.
Компилятор же формирует код, который именно так и работает.
Substitution model, собственно.