Я просто делюсь своими опытом, у нас большая команда, в ней есть новички и опытные ребята, у нас много разных заказчиков.
Мы работаем асинхронно, у нас есть общие 3-4 часа в день, но даже в них мы не ждём моментального ответа. В среднем в день мы разговариваем голосом около двух часов.
Сравнивая с офисом, мы справляемся плюс минус также.
Мой посыл не в том что все срочно переходите асинхронный процесс, а в том что это тоже может работать хорошо. Конечно, где то хуже, а где то лучше
Нужно постоянно быть на связи, соответственно всем нужно работать в одно время и не отключать нотификации.
Нет возможности выключить связь и поработать пару часов сфокусированно над чем то
Блокировки это плохо, я предлагаю перестроить процессы так, что бы минимизировать блокировки.
Асинхронный процесс не предполагает что люди изолированы и не отвечают неделями или днями, ожидать ответа в течении дня — вполне нормально.
Этого хватает чтобы не раздувать WIP, в течении дня люди как правило могут найти чем себя занять и не простаивать, зато убирает синхронную комуникацию которую тяжело поддерживать на удаленке
В идеале, вы должны ответить на вопрос в месенджере сразу, как если бы вы оба сидели в одной комнате.
Совершенно не согласен, вся прелесть и удобство удаленной работы начинается тогда, когда синхронные процессы (моментальные ответы), переходят в асинхронные, т.е. когда я задаю вопрос, не жду моментального ответа и двигаюсь дальше.
Каждый работает в своем темпе, обсуждает что-то вместе на встречах, которые запланированы заранее
Откуда информация что reduce должен проходить обязательно по всем элементам коллекции?
Вот map — да, подразумевает обход всех элементов. reduced в clojureScript, по большому счету — дополнительный внутренний флаг isReduced по которому происходит выход из reduce.
Вся прелесть в том, что при правильном именовании функций и переменных вам не нужно идти и изучать детали реализации. Вот же, прямо в коде написано, отфильтруй по признаку isKitten, а затем получи имя.
Это скорее непривычно поначалу, записи типа
const sum = a => b => a + b
console.log(sum(2)(3))
мне первое время давались с трудом, а теперь жить без них не могу :)
По большому счету, в js map — это сахар на while, посмотрел здесь: map Polyfill.
Код в примере использует map и filter, вместо одного for, вероятно, что он работает в 2 раза медленнее.
Код статьи написан в функциональном стиле, т.е. не мутирует переменных и использует чистые функции.
Действительно, основополагающие принципы у обеих парадигм одинаковые, но их реализация имхо ортогональна, поэтому говорить что ООП впитал ФП не совсем корректно
p.s. А как бы вы переписали код из статьи на JS?
Остановитесь, сайты жрут все cpu и грузятся долго не потому что ФП, map, filter или reduce, а потому что разработчик раздолбай. Говно код можно писать в любой парадигме и на любом языке.
А вот что бы на количестве функций экономить, это я от вас первый раз услышал рекомендацию, спасибо :)
Конечно зависит, сильно зависит. Но я, в своем фронтенде, в 99% случаев готов идти на такие компромиссы. Я пока не сталкивался с вещами, где несколько лишних функций сыграли бы хоть какую-то роль, хотя не отрицаю того что такие вещи где-то есть.
В узких местах — возможно, но мы каждый день пишем огромное количество кода, который не является узким местом. Интерфейс, скорее всего, не будет лагать если мы напишем map вместо for.
Конечно, глубоко внутри все сплошная императивщина, но ее уже написали для нас, давайте этим пользоваться и писать красивый, декларативный код :)
Что именно вы подразумеваете под «пользуюсь страницей первого»? Вы пользуетесь ей в своем приложении или на вк.ком? Если в приложении, то какими именно возможностями вы располагаете?
Имхо, проблема действительно описана очень размыто.
Вообще, мне кажется я понял в чем дело, авторизация через oAuth происходит условно в два этапа:
1. Юзер авторизовывается на vk.com
2. Юзер авторизовывается в вашем приложении через oAuth. Здесь вам, как разработчику, дают access token для дальнейшей работы с данными пользователя.
Когды вы пытаетесь разлогинить пользователя, вы даете ему выйти из аккаунта на vk.com (Но не в вашем приложении!). Таким образом, access token продолжает храниться на вашей стороне, и, по всей видимости, когда новый юзер авторизовывается, второго этапа авторизации в вашем приложении не происходит, т.к. у вашего приложения уже есть действительный access token предыдущего юзера. Т.е. проблема безопастности исключительно на вашей стороне, вы не позаботились о том, что бы после завершения сессии пользователя почистить все его данные авторизации.
Поправьте меня если я не прав и не могли бы вы показать ваш запрос в ТП и их ответ?
Конечно должен, проблема в том, что автор статьи делает логаут просто на сайте вк :
vk.com/login.php?op=logout
А для логаута из vk oAuth нужно использовать другой адрес, что-нибудь вроде такого:
https://oauth.vk.com/logout
В целом, все выглядит логично, пользователь может продолжать использовать какой то ресурс, на котором авторизовался с помощью oAuth, даже если непосредственно сам контакт, использует другой человек. Собственно в документации vk написано следующее:
Доверенные приложения могут получить неограниченный по времени access token для доступа к API, передав логин и пароль пользователя.
Выдаваемый access token не привязан к IP-адресу пользователя, поэтому его достаточно для последующей работы с API без повторения процедуры авторизации.
Токен пользователя П1 в куках разве не перезаписывается токеном пользователя П2? Подменой кук на валидные «ломается» любой oAuth, тут ничего не поделать
Очень советую добавить стилей, работы на час, зато как преобразится ваш тренажер. Из курсового проекта, в боевой продукт. И студенты сразу обрадуются, что им тесты современно оформленные дают, а не голый html 1995 года выпуска.
Кстати, все вопросы можно генерировать перед началом теста, что бы к вопросам всегда можно было вернуться, и исправить ошибку.
Я просто делюсь своими опытом, у нас большая команда, в ней есть новички и опытные ребята, у нас много разных заказчиков.
Мы работаем асинхронно, у нас есть общие 3-4 часа в день, но даже в них мы не ждём моментального ответа. В среднем в день мы разговариваем голосом около двух часов.
Сравнивая с офисом, мы справляемся плюс минус также.
Мой посыл не в том что все срочно переходите асинхронный процесс, а в том что это тоже может работать хорошо. Конечно, где то хуже, а где то лучше
Нужно постоянно быть на связи, соответственно всем нужно работать в одно время и не отключать нотификации.
Нет возможности выключить связь и поработать пару часов сфокусированно над чем то
Асинхронный процесс не предполагает что люди изолированы и не отвечают неделями или днями, ожидать ответа в течении дня — вполне нормально.
Этого хватает чтобы не раздувать WIP, в течении дня люди как правило могут найти чем себя занять и не простаивать, зато убирает синхронную комуникацию которую тяжело поддерживать на удаленке
Совершенно не согласен, вся прелесть и удобство удаленной работы начинается тогда, когда синхронные процессы (моментальные ответы), переходят в асинхронные, т.е. когда я задаю вопрос, не жду моментального ответа и двигаюсь дальше.
Каждый работает в своем темпе, обсуждает что-то вместе на встречах, которые запланированы заранее
Вот map — да, подразумевает обход всех элементов.
reduced в clojureScript, по большому счету — дополнительный внутренний флаг isReduced по которому происходит выход из reduce.
Это скорее непривычно поначалу, записи типа
мне первое время давались с трудом, а теперь жить без них не могу :)
Код в примере использует map и filter, вместо одного for, вероятно, что он работает в 2 раза медленнее.
Действительно, основополагающие принципы у обеих парадигм одинаковые, но их реализация имхо ортогональна, поэтому говорить что ООП впитал ФП не совсем корректно
p.s. А как бы вы переписали код из статьи на JS?
А вот что бы на количестве функций экономить, это я от вас первый раз услышал рекомендацию, спасибо :)
Лишние лямбды кушать не просят, а если вас волнуют лишние циклы используйте трансдьюсеры.
ФП — инструмент, выбирайте инструмент исходя из задачи. Вопрос применимости конкретных инструментов обсуждался уже тысячу раз :)
Конечно, глубоко внутри все сплошная императивщина, но ее уже написали для нас, давайте этим пользоваться и писать красивый, декларативный код :)
Имхо, проблема действительно описана очень размыто.
Вообще, мне кажется я понял в чем дело, авторизация через oAuth происходит условно в два этапа:
1. Юзер авторизовывается на vk.com
2. Юзер авторизовывается в вашем приложении через oAuth. Здесь вам, как разработчику, дают access token для дальнейшей работы с данными пользователя.
Когды вы пытаетесь разлогинить пользователя, вы даете ему выйти из аккаунта на vk.com (Но не в вашем приложении!). Таким образом, access token продолжает храниться на вашей стороне, и, по всей видимости, когда новый юзер авторизовывается, второго этапа авторизации в вашем приложении не происходит, т.к. у вашего приложения уже есть действительный access token предыдущего юзера. Т.е. проблема безопастности исключительно на вашей стороне, вы не позаботились о том, что бы после завершения сессии пользователя почистить все его данные авторизации.
Поправьте меня если я не прав и не могли бы вы показать ваш запрос в ТП и их ответ?
Конечно должен, проблема в том, что автор статьи делает логаут просто на сайте вк :
А для логаута из vk oAuth нужно использовать другой адрес, что-нибудь вроде такого:
В целом, все выглядит логично, пользователь может продолжать использовать какой то ресурс, на котором авторизовался с помощью oAuth, даже если непосредственно сам контакт, использует другой человек. Собственно в документации vk написано следующее:
Кстати, все вопросы можно генерировать перед началом теста, что бы к вопросам всегда можно было вернуться, и исправить ошибку.