Comments 18
Как и зачем? (на КДПВ)
это грузовой корабль тащущий корпуса для других
на фото Blue Marlin
Трудно поверить, но это не фейк.
Из интернетов:
«Blue Marlin – представляет собой корабль с огромной площадью на палубе для перевозки крупногабаритных грузов, в том числе и других кораблей. Особенностью этого корабля дока является способ загрузки плавучих грузов.
Технические характеристики корабля дока Blue Marlin:
(данные характеристики корабль получил после реконструкции в 2004 году)
Полная грузоподъемность 76 000 тонн
Площадь палубы 11 227 m2 (63 м x 178,2 м)
Скорость хода на балласте 13,3 узлов
Общая длина 224,8 метра
Глубина погружения палубы 13,3 метра
Экипаж 24 человека
Мощность дизельного двигателя: 17 000 л.с.
IMO: 9186338
MMSI: 306589000
Blue Marlin построен в 1999 году, введен в эксплуатацию 25 апреля 2000 года, но в 2004 году он претерпел существенную модернизацию, в частности добавились новые двигатели для маневренности, увеличилась возможность погружения на большую глубину и существенно увеличилась полезная площадь палубы. Палуба была расширена для возможности перевозить крупные буровые платформы. Рекордом за всю историю стало перемещение платформы Thunder Horse PDQ общим весом 60000 тонн.
Если нужно загрузить иной корабль на палубу или плавучую боровую платформу, то Blue Marlin погружается вводу так, что палуба, на которой будет находиться груз, находится ниже ватерлинии, далее этот корабль – док в полузатопленном положении подводится под габаритный плавучий груз и начинает всплытие. В конечном итоге плавучий груз оказывается на палубе этого плавучего дока и может транспортироваться в любую точку по воде.
Корабль – док оборудован 60 каютами для экипажа и лиц, которые сопровождают груз, тренажерным залом, сауной и бассейном.
В ноябре 2005 года судно «Blue Marlin» вышло из порта Корпус-Кристи, штат Техас, для перемещения радара морского базирования Х-диапазона в Адак, Аляска, через южную оконечность Южной Америки и Перл-Харбор, Гавайи. Судно прибыло в Перл-Харбор 9 января 2006 года, пройдя 15 000 миль. В январе 2007 года судно «Blue Marlin» было нанято для перевозки двух самоподъемных буровых установок, Rowan Gorilla VI и GlobalSantaFe Galaxy II, из Галифакса в Северное море.
Пятиэтажный «штабель» из речных судов и понтонов был погружен на судно в шанхайском порту Наньтун, после чего судно MV Blue Marlin отправилось в путь и спустя 58 дней, 22 марта, прибыло в Нидерланды, в порт назначения.
ВМС США использовали судно «Blue Marlin» для перевозки эсминца USS Cole обратно в Соединенные Штаты после того, как корабль был поврежден в результате террористической атаки террориста-смертника из Аль-Каиды в Адене, одном из портов. Во второй половине 2003 года, судно «Blue Marlin» прошло реконструкцию, в результате которой была увеличена емкость и добавлены два убирающихся движителя для улучшения маневренности.»
Из интернетов:
«Blue Marlin – представляет собой корабль с огромной площадью на палубе для перевозки крупногабаритных грузов, в том числе и других кораблей. Особенностью этого корабля дока является способ загрузки плавучих грузов.
Технические характеристики корабля дока Blue Marlin:
(данные характеристики корабль получил после реконструкции в 2004 году)
Полная грузоподъемность 76 000 тонн
Площадь палубы 11 227 m2 (63 м x 178,2 м)
Скорость хода на балласте 13,3 узлов
Общая длина 224,8 метра
Глубина погружения палубы 13,3 метра
Экипаж 24 человека
Мощность дизельного двигателя: 17 000 л.с.
IMO: 9186338
MMSI: 306589000
Blue Marlin построен в 1999 году, введен в эксплуатацию 25 апреля 2000 года, но в 2004 году он претерпел существенную модернизацию, в частности добавились новые двигатели для маневренности, увеличилась возможность погружения на большую глубину и существенно увеличилась полезная площадь палубы. Палуба была расширена для возможности перевозить крупные буровые платформы. Рекордом за всю историю стало перемещение платформы Thunder Horse PDQ общим весом 60000 тонн.
Если нужно загрузить иной корабль на палубу или плавучую боровую платформу, то Blue Marlin погружается вводу так, что палуба, на которой будет находиться груз, находится ниже ватерлинии, далее этот корабль – док в полузатопленном положении подводится под габаритный плавучий груз и начинает всплытие. В конечном итоге плавучий груз оказывается на палубе этого плавучего дока и может транспортироваться в любую точку по воде.
Корабль – док оборудован 60 каютами для экипажа и лиц, которые сопровождают груз, тренажерным залом, сауной и бассейном.
В ноябре 2005 года судно «Blue Marlin» вышло из порта Корпус-Кристи, штат Техас, для перемещения радара морского базирования Х-диапазона в Адак, Аляска, через южную оконечность Южной Америки и Перл-Харбор, Гавайи. Судно прибыло в Перл-Харбор 9 января 2006 года, пройдя 15 000 миль. В январе 2007 года судно «Blue Marlin» было нанято для перевозки двух самоподъемных буровых установок, Rowan Gorilla VI и GlobalSantaFe Galaxy II, из Галифакса в Северное море.
Пятиэтажный «штабель» из речных судов и понтонов был погружен на судно в шанхайском порту Наньтун, после чего судно MV Blue Marlin отправилось в путь и спустя 58 дней, 22 марта, прибыло в Нидерланды, в порт назначения.
ВМС США использовали судно «Blue Marlin» для перевозки эсминца USS Cole обратно в Соединенные Штаты после того, как корабль был поврежден в результате террористической атаки террориста-смертника из Аль-Каиды в Адене, одном из портов. Во второй половине 2003 года, судно «Blue Marlin» прошло реконструкцию, в результате которой была увеличена емкость и добавлены два убирающихся движителя для улучшения маневренности.»
Офигенная статья!
Скажите, а сколько Android-разработчиков в Вашей команде?
Скажите, а сколько Android-разработчиков в Вашей команде?
юнит-тесты запускаются на реальных устройствах
Ох лол… // Robolectric, mocked android.jar, plain java модули, etc
Привет от Android команды Yandex.Mail :)
Привет :) спасибо за коммент.
В общем, если это был не троллинг, то ответ такой:
Если целью коммента было набросить говна на вентилятор, то ответ такой:
Некоторые и женщин искусственных выбирают, — как говорится, каждому своё
В общем, если это был не троллинг, то ответ такой:
- Я не исключаю других вариантов, я лишь хотел рассказать о том, как это делаем мы.
- Об этих техниках мы прекрасно знаем и, возможно, пользовались бы, если бы не отбросили их в самом начале. Тут более уместна формулировка «почему на девайсах?», — потому что сам по себе запуск unit тестов без девайса не дает никаких преимуществ, но в свою очередь, требует отдельной настройки. В нашем случае это отдельный вид агентов, который должен работать на отдельном железе. Отсюда различия мне на данный момент видятся такие:
- девайс дешевле
- легче перераспределяются ресурсы, если агенты универсальны (агент для юнит тестов может выполнять задачи по ui тестированию и наоборот)
- дешевле поддержка однотипных агентов.
- Ориентироваться в построении процесса сборки стоит, как мне кажется, на результат, а не на процесс, поэтому мы стараемся детально анализировать результат, получаемый от каждого изменения\нововведения, если профита нет, то тратить на какую-то плюшку свой временной ресурс мы не станем.
Одним из таких условий может быть «запрет на покупку дополнительных девайсов», у нас такой проблемы нет. - Отдельно, я бы еще отметил, что за счет такого подхода мы ловили совсем случайные баги, связанные, например, с памятью. Понятно, что это можно проверять отдельно, но это в том случае если знаешь где потенциальная проблема. В нашем кейсе, скорее всего, мы бы пропустили этот баг и поймали бы его намного позже.
Если целью коммента было набросить говна на вентилятор, то ответ такой:
Некоторые и женщин искусственных выбирают, — как говорится, каждому своё
Это был не троллинг :)
Это не так, запуск юнит тестов на JVM дает два больших преимущества:
1. Скорость, тесты на JVM гонятся в гораздо быстрее чем на устройствах
2. Не нужно подключать устройство для запуска тестов, а на CI не нужно поднимать эмуляторы, которые еще медленнее, чем девайсы.
Судя по статье вы запускаете не все юнит тесты на каждый билд, очевидно, из-за скорости их работы, хотя это просто отметает весь смысл в юнит тестах т.к. их основное назначение — быстро проверить работоспособность кода.
Чем компьютер на котором уже собирается билд? Дешевле чем $0? :)
Не вижу противоречий с тестами на JVM.
Я просто слабо себе представляю процесс разработки, если бы мне приходилось подключать девайс или поднимать эмулятор чтобы просто прогнать юнит тесты.
В Yandex.Mail мы боремся со скоростью работы JVM тестов, тк весь набор выполняется пару минут, запускаем параллельно и всё такое… Был удивлен, что кто-то гоняет юнит тесты на девайсах и пишет, что всё ок :)
Но, энивей, спасибо за то, что делитесь своим опытом!
потому что сам по себе запуск unit тестов без девайса не дает никаких преимуществ
Это не так, запуск юнит тестов на JVM дает два больших преимущества:
1. Скорость, тесты на JVM гонятся в гораздо быстрее чем на устройствах
2. Не нужно подключать устройство для запуска тестов, а на CI не нужно поднимать эмуляторы, которые еще медленнее, чем девайсы.
Судя по статье вы запускаете не все юнит тесты на каждый билд, очевидно, из-за скорости их работы, хотя это просто отметает весь смысл в юнит тестах т.к. их основное назначение — быстро проверить работоспособность кода.
девайс дешевле
Чем компьютер на котором уже собирается билд? Дешевле чем $0? :)
легче перераспределяются ресурсы, если агенты универсальны (агент для юнит тестов может выполнять задачи по ui тестированию и наоборот)
Не вижу противоречий с тестами на JVM.
Я просто слабо себе представляю процесс разработки, если бы мне приходилось подключать девайс или поднимать эмулятор чтобы просто прогнать юнит тесты.
В Yandex.Mail мы боремся со скоростью работы JVM тестов, тк весь набор выполняется пару минут, запускаем параллельно и всё такое… Был удивлен, что кто-то гоняет юнит тесты на девайсах и пишет, что всё ок :)
Но, энивей, спасибо за то, что делитесь своим опытом!
ок, профит про скорость я понял, цифра в 2 минуты безусловно хороша сама по себе, но я бы предпочел иметь для сравнения вторую цифру, — запуск того же набора тестов на девайсе. На мой взгляд, тогда 2 минуты станут репрезентативными для оценки преимуществ того или иного подхода. Дело в том, что я буквально то же самое слышу про решения, которые используются другими командами, каждый хвалит свое болото. В принципе это нормально, и я привык искать причину таких решений, а потом оценивать насколько это актуально в моих проблемах и задачах, а не пытаться объяснить все факты банальной тупостью всех окружающих. Спасибо за информацию, ваш поинт я услышал, на досуге попробуем померить и если прирост в скорости будет существенным, то непременно заново рассмотрим такую возможность.
Насчет того что не все тесты запускаются, здесь, к сожалению, вы не поняли изначальную мысль. Идея заключается в том, чтобы разделить проверку работоспособности кода и интеграционные проверки, то есть проверка выполнения контракта по взаимодействию клиента и сервера.
Про разделение агентов тоже к сожалению, вы меня не поняли. Когда инфраструктура разрастается и количество задач порядочно увеличивается, то необходимо разделять обязанности агентов. Собирать 15 билдов параллельно на одной машине будет не быстрее, чем собирать их последовательно. Это влечет за собой либо увеличение вычислительной мощности одной машины, либо разделение на несколько машин. Поэтому не буду опровергать утверждение про $0, надеюсь, что вы поделитесь тем, как этого можно добиться.
Говоря о приоритетах, главным приоритетом для нас является проверка качества для конечного пользователя, а они используют приложение на девайсах.
Экономия это не главный приоритет у нас на данный момент, поэтому наши точки зрения расходятся.
В этом мире столько удивительных вещей, вы просто себе не представляете! Еще мы делаем приложение лучше и удобнее для пользователя, а не боремся с JVM, надеюсь, что это вас также не разочарует :)
К сожалению переписка в комментах не самый эффективный инструмент обмена информацией :)
Насчет того что не все тесты запускаются, здесь, к сожалению, вы не поняли изначальную мысль. Идея заключается в том, чтобы разделить проверку работоспособности кода и интеграционные проверки, то есть проверка выполнения контракта по взаимодействию клиента и сервера.
Про разделение агентов тоже к сожалению, вы меня не поняли. Когда инфраструктура разрастается и количество задач порядочно увеличивается, то необходимо разделять обязанности агентов. Собирать 15 билдов параллельно на одной машине будет не быстрее, чем собирать их последовательно. Это влечет за собой либо увеличение вычислительной мощности одной машины, либо разделение на несколько машин. Поэтому не буду опровергать утверждение про $0, надеюсь, что вы поделитесь тем, как этого можно добиться.
Говоря о приоритетах, главным приоритетом для нас является проверка качества для конечного пользователя, а они используют приложение на девайсах.
Экономия это не главный приоритет у нас на данный момент, поэтому наши точки зрения расходятся.
В Yandex.Mail мы боремся со скоростью работы JVM тестов, тк весь набор выполняется пару минут, запускаем параллельно и всё такое… Был удивлен, что кто-то гоняет юнит тесты на девайсах и пишет, что всё ок :)
В этом мире столько удивительных вещей, вы просто себе не представляете! Еще мы делаем приложение лучше и удобнее для пользователя, а не боремся с JVM, надеюсь, что это вас также не разочарует :)
К сожалению переписка в комментах не самый эффективный инструмент обмена информацией :)
цифра в 2 минуты безусловно хороша сама по себе, но я бы предпочел иметь для сравнения вторую цифру, — запуск того же набора тестов на девайсе
Согласен, к сожалению, не знаю сколько наши юнит и интеграционные тесты будут выполнятся на устройстве, предполагаю, около 8-10 минут. Могу лишь сказать их текущее количество 730 (увеличиваем с каждым дрём и новый код покрывать обязательно), есть еще функциональные тесты, их порядка 200-300, но они на устройствах.
Собирать 15 билдов параллельно на одной машине будет не быстрее, чем собирать их последовательно.
Мм, я не об этом говорил, но в целом, на 32х ядерной машинке с 96гб памяти параллельно будет быстрее :)
Про $0 на JVM тесты я имел в виду то, что для запуска JVM тестов не требуется ничего кроме текущей машины, на которой собирается билд, а для запуска на устройстве/эмуляторе требуется, собственно, устройство/эмулятор.
Говоря о приоритетах, главным приоритетом для нас является проверка качества для конечного пользователя, а они используют приложение на девайсах.
Не вижу связи с запуском юнит тестов на устройствах.
В этом мире столько удивительных вещей, вы просто себе не представляете! Еще мы делаем приложение лучше и удобнее для пользователя, а не боремся с JVM, надеюсь, что это вас также не разочарует :)
Напротив, я очень рад, что вы тестируете Android проекты! Просто удивлен некоторыми деталями %)
А зачем вы сборку распараллелили не до конца? Почему все 24 сборки не сделать параллельными?
И еще вопрос по сборкам iOS приложений. Я делал CI для iOS приложений, и у меня получились какие-то велокостыли (хотя работает ОК). Хотелось бы узнать, как вы делаете.
И еще вопрос по сборкам iOS приложений. Я делал CI для iOS приложений, и у меня получились какие-то велокостыли (хотя работает ОК). Хотелось бы узнать, как вы делаете.
Есть такие идеи, но пока время на сборку не переваливает за какие-то пороги. Большую часть времени в сборке все равно занимают UI тесты, соответственно, пока это не самое узкое место.
А с какими проблемами вы столкнулись при сборке iOS приложений?
А с какими проблемами вы столкнулись при сборке iOS приложений?
Просто для бамбу было бы удобнее наверное иметь все 24 сборки в отдельных job-ах. Так ими и управлять гибче можно, и поддерживать.
Не сказать, что я столкнулся с какими-то особенными проблемами при сборке. Нативные swift-приложения собираются легко. Unity сложнее, но тоже в принципе решаемо. А вот менеджить сертификаты подписей в крупной фирме оказалось делом непростым. У Apple очень хитрая и не очень надежная система аккаунтов, кмк не до конца еще отработанная. Вот тут были и остаются проблемы.
Не сказать, что я столкнулся с какими-то особенными проблемами при сборке. Нативные swift-приложения собираются легко. Unity сложнее, но тоже в принципе решаемо. А вот менеджить сертификаты подписей в крупной фирме оказалось делом непростым. У Apple очень хитрая и не очень надежная система аккаунтов, кмк не до конца еще отработанная. Вот тут были и остаются проблемы.
Ох, ребята, когда mail.ru научится делать папки более второго уровня вложенности, а?
Интересует Ваш подход к устранению замечаний lint. С уровнем error — понятно (обязательно нужно устранить). А как поступаете с уровнем warning? Допускается ли их наличие? Если да, то в какой момент (при каком объеме) от них избавляетесь?
Просматриваем замечания, если мы считаем, что замечание справедливое и его действительно нужно учитывать при разработке, то переводим в настройках lint конкретный ворнинг в статус error, фейлим билд в дальнейшем, если подобные ошибки еще будут допущены.
Если же замечание несущественное, либо мы не готовы пока исправлять это замечание, то делаем это ворнингом и билд пропускаем.
Бывает, что ошибке присвоен уровень warning, потому что нет возможности однозначно определить ошибка это или нет, в таком случае мы пользуемся supressWarning аннотацией, либо добавляем конкретный участок кода в исключения. Здесь главное, как я считаю — держать exclude фильтры как говорится «as short as possible», в идеале, конечно их вообще не должно быть.
Если же замечание несущественное, либо мы не готовы пока исправлять это замечание, то делаем это ворнингом и билд пропускаем.
Бывает, что ошибке присвоен уровень warning, потому что нет возможности однозначно определить ошибка это или нет, в таком случае мы пользуемся supressWarning аннотацией, либо добавляем конкретный участок кода в исключения. Здесь главное, как я считаю — держать exclude фильтры как говорится «as short as possible», в идеале, конечно их вообще не должно быть.
UFO just landed and posted this here
Sign up to leave a comment.
Немного о сборке мобильного приложения