Шкаф, нет слов, одни междометия.
Как человек, уже больше 20 лет катающийся ежегодно на «ночном» — 13 часов, выезд вечером — маршруте, для которого, судя по всему и предназначены эти вагоны, я не могу понять как можно: Засунуть 6 человек в и так закрытое помещение а затем снизить количество осязаемого пространства еще больше, поставив шкаф и закрыв нормальный вид на окно для тех кто сидит не прямо около него.
Сейчас пассажиры верхних полок сидят спокойно на нижней, пока пассажир нижней не ложится спать, и ни у кого это не вызывает проблем (кроме некоторых уникальных людей). В схеме со шкафом это уже невозможно — если человек лежит то и столик выдвижной не поможет, там негде сесть, там — ноги. Пассажирам нижней тоже подгадили — надо на карачках пробираться к окну.
Если уж делаете «для интровертов» — лучше сделайте настоящие капсулы, по 1 в ряд, вход только сбоку, можно только спать.
Багаж. Габариты отсеков шкафа подразумевают раскладывание багажа из чемодана что ли? Или в поезд будем сажать как на победе: измеряя габариты, чтобы влезали в шкаф? Под сиденье уже нереально поставить большой чемодан на двоих (или двоих с детьми). Про верхнюю полку и говорить нечего.
Верхняя полка. ЧЕМ вам помешала багажная полка? Человек на втором ярусе залез туда не сидеть (нереально все время поездки полулёжа-лёжа провести), а третья полка сейчас находится на такой высоте, чтобы было удобно человеку среднего роста докинуть снизу свой багаж. Даже если будет та самая недополка что на рендерах — она как раз съест то место которое вы выиграли, убрав третью, багажную полку.
Не вижу даже малейшего применения окошкам в перегородках на втором ярусе
Сиденья на первом ярусе не в боковушках: как предполагается вылезать человеку сидящему у окна в купе со шкафом?
Что то мне кажется, что при реализации дизайна вагона не учли основное: там будут разные люди. старые бабульки, толстые мужики, женщины с детьми а не только идеальные молодые стройные спортивные которым все эти сложности (в особенности багаж) — нафиг не нужны, они с кошельком путешествуют.
Скорее всего вы правы. Меня, видимо, смутило, что про такую зависимость говорится не в разделе dependencies: а в разделе needs:
needs: is similar to dependencies: in that it must use jobs from prior stages, meaning it’s impossible to create circular dependencies. Depending on jobs in the current stage is not possible either, but support is planned.
с autoscaling я думаю речь идет про autoscaling on AWS: Gitlab скейлит раннеры на EC2 и на fargate.
Про HA — я подозревал, что так и есть, обычное дело.
И спасибо про пояснение про phases\stages, я протупил. При использовании DAG(needs: keyword) они планируют добавить возможность зависимостей джобов и внутри одного стейжа тоже (сейчас джоба может зависеть только от джобы из предыдущего стейжа)
к сожалению, у автора точно так же, я не понял.
С другой стороны, ru_vds ссылается на статью на DZone которые ссылаются на оригинал на lambdatest
В обоих статьях до перевода явно сквозит то, что что сравнение инструментов производилось из разреза DevOps Testing, в оригинале она даже заканчивается словами «Счастливого тестирования».
Возможно, с точки зрения QA специалиста, пользующегося данными инструментами, какие то пункты, про которые пишут в комментариях будут иметь смысл. Сам я не могу посмотреть с точки зрения тестирования на эти инструменты — не занимаюсь тестированием.
Немного удивило про поддержку в таблице, что у Jenkins ее нет а у gitlab есть.
Учитывая что большую часть проблем что с одним что с другим приходится решать все равно через community (в гитлабе в ишьюсах люди пишут свои костыли как обойти недоработки Gitlab CI) — может быть имелась в виду коммерческая поддержка?
И к этой ситуации выше есть как раз комментарий 13werwolf13, что проблемы CI «не решаются» — на самом деле решаются но долго, вопрос приоритизации
«Нельзя протестировать результаты объединения веток до их фактического объединения» уже написал VolCh — но эта фича доступна только в платных планах
«Для каждой задачи нужно описывать и загружать/выгружать артефакты.» — без использования DAG артефакты достаточно описать, они будут доступны следующему стейжу по умолчанию, если не изменяет память. (мне удобнее зависимости задач прописывать, поэтому верю документации без проверки)
Ну и много вопросов к таблице, как это все на самом деле относится к CI как инструменту?:
«Мониторинг производительности приложений, Поддержка JavaScript»
«Интеграция с другими инструментами, Уникальные особенности, Установка» — несравнимые вещи для дженкинса, который отдельный инструмент и gitlab-ci, который часть платформы
Фамилия Шварценеггер — австрийская. Многие считают, в том числе и знаменитый носитель фамилии, что фамилия состоит из двух основ: Schwarzen + Egger, что означает «чёрный пахарь»
Интересно у вас получилось. Знакомо :D
У нас нет выделенного скрам-мастера (какие-то, важные для команды, задачи этой роли выполняю в основном я)
Однажды мы провели «ретроспективу на спринт-ретроспективы» и заменили их спринт-ревью. Один из пунктов ревью — формирование списка проблем: кто какие проблемы в нашей работе во время спринта видит. При наличии проблем — делаем разбор конкретной проблемы. Если проблемы не замечены — значит нечего и разбирать.
И да, записываем соглашения по работе внутри команды.
Скрам — это, в общем-то, инструмент. И если он мешает работе — его можно выбросить (или подпилить под свои нужды как получилось у вас и у нас)
Strongswan, из текущего продакшн опыта
+ Легко и непринужденно работает подключение ikev2/ipsec в Windows
— Легко и непринужденно обновление Windows(особенно 10-ки) вызывает необходимость дебажить что же такое поменяли MS в дефолтных параметрах ipseс и как это исправить — или же параметры надо строго фиксировать сразу, при изначальной настройке (или в скрипте настройки). Особая весёлость что на каком то этапе в Win10 часть настроек ipsec были только через powershell а другая только через netsh. Я так и не понял, то ли не все параметры в коммандлеты завезли то ли что
Отдельная конфигурация для MacOS. Отдельный геморрой с настройкой через оригинальный клиент. Так и не удалось победить привязку к радиусу AD (и через консольный клиент strongswan тоже) — пароли хранятся статически открытым текстом в файлике ipsec.secrets на сервере.
Отдельная конфигурация для Linux клиентов. Тут хоть все работает более-менее. Через консоль. Network Manager плагин работает если его правильно собрать — то есть, если память не изменяет, в Fedora он собран, а во многих других дистрах через интерфейс — хрен (информация годовой давности, после чего забил). Использование централизованной аутентификации через AD опять же падает по непонятным причинам и не работает, пароли статические.
Проблемы с радиусом отношу к своей криворукости но не нашел ни одного адекватного способа отдебажить что там не так, без неадекватных затрат времени. Но в итоге централизованная аутентификация через AD — только на Win.
+ Легко и непринужденно работаем с конфигами (автоподъем в случае смерти сервера возвращает все взад).
— Нет OTP в оригинальном решении. Можно использовать проприетарное решение от кого-нибудь, кто уже реализовал OTP, но опенсорсом тут тогда и не пахнет.
— двойной нат от провайдера зачастую делает ipsec туннель неработоспособным.
При этом OpenVPN (возьмите хотя бы pritunl) решает именно такие задачи относительно просто, обеспечивает вас ТЫСЯЧЕЙ гайдов по настройке и просто работает. И, конечно, имеет свои проблемы.
Советовать протокол (против «Other VPN») а не реализацию для организации доступа пользователей, при том что протокол хорош, конечно, — я бы вот так не стал. Уж лучше тогда WG рекламировать чтобы на него побольше перешло и побыстрее появились обвязки с OTP и прочая, чего ему не хватает для нормального использования.
И фразу про «книгу Евгения Брикмана» тоже неплохо было бы в начале разместить. Повествование начинается так «с места в карьер» и непонятно то ли это часть серии статей или что.
Специально перечитал все комментарии чтобы найти этот(так и думал что не мне одному эта идея пришла в голову). Сам этот пост просто нуждается быть размещенным на Habr.Конкурс и, насколько я помню по опросам хабровчан — подобное проводится довольно регулярно.
Ну и другим авторам дать возможность проводить такие конкурсы
Еще заметил, что если на первом совещании я не молчу, а говорю – ну там, в обсуждении участвую – то результат получается хуже. Поэтому прям заставлял себя молчать.
Вот не тугодум же ни разу — вы точно так же как и все остальные имеете какие-то мысли, идеи во время первого совещания. Просто вас уже заранее не устраивает качество этих идей и вы продолжаете думать о том как улучшить и как сделать качественное решение после совещания.
в «модерновых», как вы их назвали, организациях, иногда быстрое решение лучше: в мире где все быстро меняется, хорошо продуманное, качественное решение, может устареть к моменту реализации. На заводе же — сами понимаете, слишком большая привязка к реальным, материальным вещам, и хорошо продуманное решение чаще выстреливает.
На себе замечаю, что во время почти любых митингов совещаний на темы, в которых считаю себя компетентным, вполне себе высказываю идеи, ищу со всеми пути решения заявленных проблем, но после — все равно иногда продолжаю думать на тему решения, причем не заставляя себя, особенно если понятно, что решения принятые на совещании, меня не устраивают по качеству реализации.
Мой комментарий, к стыду моему, действительно дает ощущение что «тест кривой».
На самом деле ожидание правильной обработки неверного запроса входит в RFC, но пока что не реализовано у AWS.
Обсуждение: forums.aws.amazon.com/message.jspa?messageID=851817
Судя по тестам, AWS отдает неверный ответ на неверный запрос: в данный момент существует только версия EDNS0 а тесты запрашивают EDNS1, которого не существует.
То есть тест спрашивает у Route53 то, чего не существует, и ожидает что AWS Route53 как-то правильно отреагирует
Я, после новостей о том, что windows 10 удаляет файлы из профиля, впервые осознал, что я не тестирую домашние бэкапы. На работе это как-то само-собой, а дома — нет. Зря, наверное.
Все верно.
Моё недоумение возникло в свете того, что есть отличный инструмент управления инфраструктурой(т.е., в том числе, и ресурсами AWS), которым удобно пользоваться.
Я же воспринимаю awscli (и его аналоги) как способ произвести некоторые действия внутри уже развернутой инфраструктуры, в скриптах, по триггеру, расписанию и т.п.
А awsless это попытка сделать «удобный awscli» — удобный инструмент управления ресурсами AWS из командной строки. В связи с этим, функционал, который описан: оффлайн слепок инфраструктуры, темплейтирование, автодополнение и т.п. мной воспринимается как: «но зачем?».
Тем не менее — пришлось немного поизучать вопрос — спрос на такие инструменты у сообщества есть.
При этом попробуйте в поиске программ набрать по буквам «обновлени».
Он при вводе каждой следующей буквы находит новый список.Разный. И при добавлении следующей буквы он может убрать из поиска пару пунктов.Этот поиск работает странно.
Как человек, уже больше 20 лет катающийся ежегодно на «ночном» — 13 часов, выезд вечером — маршруте, для которого, судя по всему и предназначены эти вагоны, я не могу понять как можно: Засунуть 6 человек в и так закрытое помещение а затем снизить количество осязаемого пространства еще больше, поставив шкаф и закрыв нормальный вид на окно для тех кто сидит не прямо около него.
Сейчас пассажиры верхних полок сидят спокойно на нижней, пока пассажир нижней не ложится спать, и ни у кого это не вызывает проблем (кроме некоторых уникальных людей). В схеме со шкафом это уже невозможно — если человек лежит то и столик выдвижной не поможет, там негде сесть, там — ноги. Пассажирам нижней тоже подгадили — надо на карачках пробираться к окну.
Если уж делаете «для интровертов» — лучше сделайте настоящие капсулы, по 1 в ряд, вход только сбоку, можно только спать.
Багаж. Габариты отсеков шкафа подразумевают раскладывание багажа из чемодана что ли? Или в поезд будем сажать как на победе: измеряя габариты, чтобы влезали в шкаф? Под сиденье уже нереально поставить большой чемодан на двоих (или двоих с детьми). Про верхнюю полку и говорить нечего.
Верхняя полка. ЧЕМ вам помешала багажная полка? Человек на втором ярусе залез туда не сидеть (нереально все время поездки полулёжа-лёжа провести), а третья полка сейчас находится на такой высоте, чтобы было удобно человеку среднего роста докинуть снизу свой багаж. Даже если будет та самая недополка что на рендерах — она как раз съест то место которое вы выиграли, убрав третью, багажную полку.
Не вижу даже малейшего применения окошкам в перегородках на втором ярусе
Сиденья на первом ярусе не в боковушках: как предполагается вылезать человеку сидящему у окна в купе со шкафом?
Что то мне кажется, что при реализации дизайна вагона не учли основное: там будут разные люди. старые бабульки, толстые мужики, женщины с детьми а не только идеальные молодые стройные спортивные которым все эти сложности (в особенности багаж) — нафиг не нужны, они с кошельком путешествуют.
при этом в разделе dependencies: — ни слова =)
Про HA — я подозревал, что так и есть, обычное дело.
И спасибо про пояснение про phases\stages, я протупил. При использовании DAG(needs: keyword) они планируют добавить возможность зависимостей джобов и внутри одного стейжа тоже (сейчас джоба может зависеть только от джобы из предыдущего стейжа)
С другой стороны, ru_vds ссылается на статью на DZone которые ссылаются на оригинал на lambdatest
В обоих статьях до перевода явно сквозит то, что что сравнение инструментов производилось из разреза DevOps Testing, в оригинале она даже заканчивается словами «Счастливого тестирования».
Возможно, с точки зрения QA специалиста, пользующегося данными инструментами, какие то пункты, про которые пишут в комментариях будут иметь смысл. Сам я не могу посмотреть с точки зрения тестирования на эти инструменты — не занимаюсь тестированием.
Учитывая что большую часть проблем что с одним что с другим приходится решать все равно через community (в гитлабе в ишьюсах люди пишут свои костыли как обойти недоработки Gitlab CI) — может быть имелась в виду коммерческая поддержка?
И к этой ситуации выше есть как раз комментарий 13werwolf13, что проблемы CI «не решаются» — на самом деле решаются но долго, вопрос приоритизации
«Нельзя протестировать результаты объединения веток до их фактического объединения» уже написал VolCh — но эта фича доступна только в платных планах
«Для каждой задачи нужно описывать и загружать/выгружать артефакты.» — без использования DAG артефакты достаточно описать, они будут доступны следующему стейжу по умолчанию, если не изменяет память. (мне удобнее зависимости задач прописывать, поэтому верю документации без проверки)
Ну и много вопросов к таблице, как это все на самом деле относится к CI как инструменту?:
«Мониторинг производительности приложений, Поддержка JavaScript»
«Интеграция с другими инструментами, Уникальные особенности, Установка» — несравнимые вещи для дженкинса, который отдельный инструмент и gitlab-ci, который часть платформы
У нас нет выделенного скрам-мастера (какие-то, важные для команды, задачи этой роли выполняю в основном я)
Однажды мы провели «ретроспективу на спринт-ретроспективы» и заменили их спринт-ревью. Один из пунктов ревью — формирование списка проблем: кто какие проблемы в нашей работе во время спринта видит. При наличии проблем — делаем разбор конкретной проблемы. Если проблемы не замечены — значит нечего и разбирать.
И да, записываем соглашения по работе внутри команды.
Скрам — это, в общем-то, инструмент. И если он мешает работе — его можно выбросить (или подпилить под свои нужды как получилось у вас и у нас)
+ Легко и непринужденно работает подключение ikev2/ipsec в Windows
— Легко и непринужденно обновление Windows(особенно 10-ки) вызывает необходимость дебажить что же такое поменяли MS в дефолтных параметрах ipseс и как это исправить — или же параметры надо строго фиксировать сразу, при изначальной настройке (или в скрипте настройки). Особая весёлость что на каком то этапе в Win10 часть настроек ipsec были только через powershell а другая только через netsh. Я так и не понял, то ли не все параметры в коммандлеты завезли то ли что
Отдельная конфигурация для MacOS. Отдельный геморрой с настройкой через оригинальный клиент. Так и не удалось победить привязку к радиусу AD (и через консольный клиент strongswan тоже) — пароли хранятся статически открытым текстом в файлике ipsec.secrets на сервере.
Отдельная конфигурация для Linux клиентов. Тут хоть все работает более-менее. Через консоль. Network Manager плагин работает если его правильно собрать — то есть, если память не изменяет, в Fedora он собран, а во многих других дистрах через интерфейс — хрен (информация годовой давности, после чего забил). Использование централизованной аутентификации через AD опять же падает по непонятным причинам и не работает, пароли статические.
Проблемы с радиусом отношу к своей криворукости но не нашел ни одного адекватного способа отдебажить что там не так, без неадекватных затрат времени. Но в итоге централизованная аутентификация через AD — только на Win.
+ Легко и непринужденно работаем с конфигами (автоподъем в случае смерти сервера возвращает все взад).
— Нет OTP в оригинальном решении. Можно использовать проприетарное решение от кого-нибудь, кто уже реализовал OTP, но опенсорсом тут тогда и не пахнет.
— двойной нат от провайдера зачастую делает ipsec туннель неработоспособным.
При этом OpenVPN (возьмите хотя бы pritunl) решает именно такие задачи относительно просто, обеспечивает вас ТЫСЯЧЕЙ гайдов по настройке и просто работает. И, конечно, имеет свои проблемы.
Советовать протокол (против «Other VPN») а не реализацию для организации доступа пользователей, при том что протокол хорош, конечно, — я бы вот так не стал. Уж лучше тогда WG рекламировать чтобы на него побольше перешло и побыстрее появились обвязки с OTP и прочая, чего ему не хватает для нормального использования.
Ну и другим авторам дать возможность проводить такие конкурсы
Вот не тугодум же ни разу — вы точно так же как и все остальные имеете какие-то мысли, идеи во время первого совещания. Просто вас уже заранее не устраивает качество этих идей и вы продолжаете думать о том как улучшить и как сделать качественное решение после совещания.
в «модерновых», как вы их назвали, организациях, иногда быстрое решение лучше: в мире где все быстро меняется, хорошо продуманное, качественное решение, может устареть к моменту реализации. На заводе же — сами понимаете, слишком большая привязка к реальным, материальным вещам, и хорошо продуманное решение чаще выстреливает.
На себе замечаю, что во время почти любых
митинговсовещаний на темы, в которых считаю себя компетентным, вполне себе высказываю идеи, ищу со всеми пути решения заявленных проблем, но после — все равно иногда продолжаю думать на тему решения, причем не заставляя себя, особенно если понятно, что решения принятые на совещании, меня не устраивают по качеству реализации.```
DISM.exe /online /Cleanup-Image /SPSuperseded
```
На самом деле ожидание правильной обработки неверного запроса входит в RFC, но пока что не реализовано у AWS.
Обсуждение: forums.aws.amazon.com/message.jspa?messageID=851817
То есть тест спрашивает у Route53 то, чего не существует, и ожидает что AWS Route53 как-то правильно отреагирует
Моё недоумение возникло в свете того, что есть отличный инструмент управления инфраструктурой(т.е., в том числе, и ресурсами AWS), которым удобно пользоваться.
Я же воспринимаю awscli (и его аналоги) как способ произвести некоторые действия внутри уже развернутой инфраструктуры, в скриптах, по триггеру, расписанию и т.п.
А awsless это попытка сделать «удобный awscli» — удобный инструмент управления ресурсами AWS из командной строки. В связи с этим, функционал, который описан: оффлайн слепок инфраструктуры, темплейтирование, автодополнение и т.п. мной воспринимается как: «но зачем?».
Тем не менее — пришлось немного поизучать вопрос — спрос на такие инструменты у сообщества есть.
Он при вводе каждой следующей буквы находит новый список.Разный. И при добавлении следующей буквы он может убрать из поиска пару пунктов.Этот поиск работает странно.