Речь идет о такого рода настройке:
«если пользователь непрерывно работает со страницей, то сессия истекает через 8 часов рабочего дня»
«если пользователь не делал никаких операций, сессия закрывается через 15 минут ожидания»
Решается это разным таймаутом валидности для access и refresh token'a.
«периодически рефрешится у IdP простым редиректом на authorize эндпоинт»
вот здесь поподробнее пожалуйста, снова пользователю пароль вводить?
Refresh Token нужен для того, чтобы можно было задавать разные таймауты для «активной» сессии (когда пользователь непрерывно работает) и для «неактивной» сессии (когда ушел не закрыв браузер).
Т.е. повышение удобства использования (реже спрашивать пароль) без значительного понижения уровня безопасности.
«0.2^6 — вероятность провалить все 6 собеседований»
соверешенно верно, нам нужно не провалить хотя бы одно (т.е. любой исход кроме того, у которого вероятность 0.2^6), потому
P = 1 — (1-0.8)^6 = 0,999936
«0.2^6 — вероятность провалить все 6 собеседований»
соверешенно верно, нам нужно не провалить хотя бы одно (т.е. любой исход кроме того, у которого вероятность 0.2^6), потому
P = 1 — (1-0.8)^6 = 0,999936
Вот вы пишите
«Если вы хорошо готовились к каждому интервью и имеете шансы на каждом собеседовании 80% из 100, что очень круто, то по теории вероятности после 6 технических интервью Ваши шансы равны 0.8^6 = 0.26.»
На самом деле, при таком раскладе, вероятность пройти после 6-ти интервью
P = 1 — (1-0.8)^6 = 0,999936
Есть потенциал для улучшения перед следующей попыткой :)
Взгляните на Cloud Foundry.
Docker — это не тот уровень абстракции, который позволяет максимально эффективно использовать 12-факторную архитектуру и серьезно скалировать разработку enterprise приложений.
Я бы даже назвал BOSH следующим поколением инструментов управления конфигурациями (типа Puppet, Chef, Ansible, Salt).
(Хотя тут есть конечно довольно существенное предварительное требование: виртуализированная инфраструктура)
А где же комментарии на тему как git flow вписывается в continuous integration и continuous delivery?
Похоже именно из-за нераскрытости этой темы github в частности не использует git flow.
Что ж, Ваш процесс разработки более напоминает open source.
За мерджы выходит ответственен тим-лид (лучше, чем в моем сценарии-страшилке).
А CI вы для каждой фитче-ветки отдельно настраиваете?
Потому что так получается, что фитча-бранч начинает играть роль нормального транка команды, которая над ним работает. А транк служит скорее средством code review.
Да и не agile это по фитча-бренчам обосабливаться.
Как по мне, если используете git, то бренчте локально сколько хотите, но в центральном репозитории количество живых ветвей надо держать минимальным.
Моя практика показывает другое. Для начальства фитчей может быть что угодно, вплоть до полной переделки программы. Не разработчки определяют, что такое фитча. Вам должно быть везло.
Если Ваша фитча — штука обосбленная, то бренч вам видимо нужен, чтобы не нести отвественность за «чужие мелкие баги».
Представляю такую разработку: Вы, как опытный специалист, обосбливаетесь в своем фитче-бренче, отлаживаете его, запускаете, проверяете аккуратно локально, потом мерджите в транк, а там «чужие мелкие баги» (если их нет, зачем бренч?). И тогда вы со спокойной душой говорите: «это не мой баг, глядите, у меня в фитче-бранче все работает, разбираетесь там сами».
Я за то, чтобы не позволять девелоперам занимать такую позицию.
У нас разработчики вообще ничего не деплоят, деплоит только билд-система.
Верно, билд будет занимать столько же, что и снепшот.
С «политикой очистки» проблема, которую я предлагаю решить с помощью отказа от снепшотов и усовершенствования maven.
Единственная «политика очистки» на сегодняшний день — это удаление снепшотов. Снепшоты обладают недостатками, поэтому нужна политика очистки не только от снепшотов.
При этом очистка это только часть темы, не буду здесь более повторяться.
Вообще-то не с того я начал. Но почему бы нет? :)
Проблему стейджинга пытаются сейчас решить все кому не лень: репозитории (Nexus), билд.системы (Go), разработчкики, вручную мастерящие CI среды. Почему бы не подумать об этом разработчикам maven, которые и так уже много чего мало относящегося к dependency management'у в pom.xml добавили.
Если разработка активна, а проект большой (наша подсистема занимает более 200Мб один билд, и это хорошо, если 6ая часть того, что попадает в нексус), устанете винты докупать :)
Нам тоже на первый взгляд так казалось, мол что такое 200Мб билд.
Но давайте посчитаем, скромно, в среднем 10 билдов в день (на самом деле куда больше, но для простоты), 2Gb в день прирост.
1Тб винта вам хватит почти на 1,5 года. Кажется много, но 1,5 года пролетают очень быстро и вот уже винт полон.
Новый стоит дешево, но его ж надо заказать, потом установить. Потом придется помучиться и расширить репозиторий на несколько винтов постфактум.
А если реально, то один срез всей нашей системы весит не 200Мб, а 1Gb и билдов не 10, а 100 в день.
Как-то жалко тратить деньги на железо и время на то чтобы сохранить кучу мусора в репозитории.
Чем не занимается maven?
Если генерацией версий, тогда да, об этом и речь, предлагаю добавить.
Если разделением на SNAPSHOT и релиз версии, то это чисто maven-овское изобретение.
«если пользователь непрерывно работает со страницей, то сессия истекает через 8 часов рабочего дня»
«если пользователь не делал никаких операций, сессия закрывается через 15 минут ожидания»
Решается это разным таймаутом валидности для access и refresh token'a.
«периодически рефрешится у IdP простым редиректом на authorize эндпоинт»
вот здесь поподробнее пожалуйста, снова пользователю пароль вводить?
Т.е. повышение удобства использования (реже спрашивать пароль) без значительного понижения уровня безопасности.
Если надо пройти все 6, то да, у девушки все верно.
Если надо пройти все 6, то да, у девушки все верно.
«0.2^6 — вероятность провалить все 6 собеседований»
соверешенно верно, нам нужно не провалить хотя бы одно (т.е. любой исход кроме того, у которого вероятность 0.2^6), потому
P = 1 — (1-0.8)^6 = 0,999936
(зачем я это разжевываю? :) )
«0.2^6 — вероятность провалить все 6 собеседований»
соверешенно верно, нам нужно не провалить хотя бы одно (т.е. любой исход кроме того, у которого вероятность 0.2^6), потому
P = 1 — (1-0.8)^6 = 0,999936
«Если вы хорошо готовились к каждому интервью и имеете шансы на каждом собеседовании 80% из 100, что очень круто, то по теории вероятности после 6 технических интервью Ваши шансы равны 0.8^6 = 0.26.»
На самом деле, при таком раскладе, вероятность пройти после 6-ти интервью
P = 1 — (1-0.8)^6 = 0,999936
Есть потенциал для улучшения перед следующей попыткой :)
Docker — это не тот уровень абстракции, который позволяет максимально эффективно использовать 12-факторную архитектуру и серьезно скалировать разработку enterprise приложений.
Я бы даже назвал BOSH следующим поколением инструментов управления конфигурациями (типа Puppet, Chef, Ansible, Salt).
(Хотя тут есть конечно довольно существенное предварительное требование: виртуализированная инфраструктура)
Уже пару лет как очень успешный стартап.
Похоже именно из-за нераскрытости этой темы github в частности не использует git flow.
За мерджы выходит ответственен тим-лид (лучше, чем в моем сценарии-страшилке).
А CI вы для каждой фитче-ветки отдельно настраиваете?
Потому что так получается, что фитча-бранч начинает играть роль нормального транка команды, которая над ним работает. А транк служит скорее средством code review.
Как по мне, если используете git, то бренчте локально сколько хотите, но в центральном репозитории количество живых ветвей надо держать минимальным.
Если Ваша фитча — штука обосбленная, то бренч вам видимо нужен, чтобы не нести отвественность за «чужие мелкие баги».
Представляю такую разработку: Вы, как опытный специалист, обосбливаетесь в своем фитче-бренче, отлаживаете его, запускаете, проверяете аккуратно локально, потом мерджите в транк, а там «чужие мелкие баги» (если их нет, зачем бренч?). И тогда вы со спокойной душой говорите: «это не мой баг, глядите, у меня в фитче-бранче все работает, разбираетесь там сами».
Я за то, чтобы не позволять девелоперам занимать такую позицию.
Верно, билд будет занимать столько же, что и снепшот.
С «политикой очистки» проблема, которую я предлагаю решить с помощью отказа от снепшотов и усовершенствования maven.
Единственная «политика очистки» на сегодняшний день — это удаление снепшотов. Снепшоты обладают недостатками, поэтому нужна политика очистки не только от снепшотов.
При этом очистка это только часть темы, не буду здесь более повторяться.
Проблему стейджинга пытаются сейчас решить все кому не лень: репозитории (Nexus), билд.системы (Go), разработчкики, вручную мастерящие CI среды. Почему бы не подумать об этом разработчикам maven, которые и так уже много чего мало относящегося к dependency management'у в pom.xml добавили.
Нам тоже на первый взгляд так казалось, мол что такое 200Мб билд.
Но давайте посчитаем, скромно, в среднем 10 билдов в день (на самом деле куда больше, но для простоты), 2Gb в день прирост.
1Тб винта вам хватит почти на 1,5 года. Кажется много, но 1,5 года пролетают очень быстро и вот уже винт полон.
Новый стоит дешево, но его ж надо заказать, потом установить. Потом придется помучиться и расширить репозиторий на несколько винтов постфактум.
А если реально, то один срез всей нашей системы весит не 200Мб, а 1Gb и билдов не 10, а 100 в день.
Как-то жалко тратить деньги на железо и время на то чтобы сохранить кучу мусора в репозитории.
Если генерацией версий, тогда да, об этом и речь, предлагаю добавить.
Если разделением на SNAPSHOT и релиз версии, то это чисто maven-овское изобретение.