Pull to refresh
0
Dmytro Kryvenko @LLIbIcpEPread⁠-⁠only

User

Send message
Выше я уже говорил о беспроводной клавиатуре. И мониторе. И мышке. Такое себе компьютер, который можно положить в карман.
А где кто говорил о вытеснении? Речь идет о том, что все это становится практически однотипным инструментом. Да и в ваших примерах, да, полного вытеснения не произошло, но разве процентное соотношение не изменилось кардинальным образом? Разве не об этом речь?
Да, давайте перестанем фантазировать, что программистов и инжинеров — 80% населения на планете. Я ведь кажется и не говорил, что в NASA ракеты будут со смартфонов запускать.
А что оно из себя представляет? Откуда железо? Где почитать о вас? Из того, что я помню, самым новым была Циска на Дворянской в моднявой стойке. Видимо, роутила всю внутреннюю сеть. А тут, суперкомпьютерные вычисления. Близко к теме моего диплома. Кто руководит всем этим?
Центр каких, простите там у вас, вычислений в ОНУ? Как давно существует?
работают только на PC

Кажется, вы путаете понятие платформы с ОС. Сейчас есть смартфоны на х86 архитектуре. Не вижу проблем.
К андроиду можно подключить монитор и клавиатуру, вероятно и мышку тоже.
Грань между PC и мобильными операционками стерта. Посмотрите на Асус Трансформер.
Да и даже без этого, когда я прихожу в магазин, я вижу очень много PC и ноутов либо без операционки, либо с каким-либо дистрибутивом линукса. Винда в комплекте сейчас — это плюс к ценнику и яркая заметная бирка.
Я думаю, они не пропали, просто нужен мощный микроскоп, что-бы их там рассмотреть.
А я вам скажу, что вы не правы. Джары не бесполезны. Это фича реализации реактора, которую можно и нужно использовать в билде продукта. Но с чего вы взяли, что модуль продукта, этот один из десяти, не может быть использован в другом продукте? Да даже его отдельный классифайр может быть использован. Может, и точка. В этом модуле может быть набор интерфейсов, который используется как API в другом продукте для интеграции с первым. Просто пример.
И в чем разница то? Билд 9 из 10 модулей в продукте — успешен, и эти 9 модулей должны быть задеплоены. Билд самого продукта завален. Вот и все. Тот же дженкинс умеет видеть модули в продукте по отдельности, анализировать метрики по отдельности, даже мейлы слать на каждый модуль отдельно. Реактор — всего лишь агрегатор, который объединяет в один билд несколько модулей. Но он не меняет концепцию.
Уровнем абстракции. Зависит от того, что вы разрабатываете — фреймворк, библиотеку, или продукт. Один единственный модуль вашего продукта А может точно так-же подтягиваться как зависимость к совершенно другому продукту Б в компании. И как мы нарушаем метрику и цикл разработки этого другого продукта Б, если вдруг билд этого модуля в продукте А был успешен, но не задеплоен, потому что atomic deploy мы так любим?
А теперь снова возвращаемся к теме, нужен ли вам atomic deploy, и правильно ли это.
Либо вы не понимаете смысл разделения на модули, либо у вас на модули продукт разделен от балды, либо и то и другое вместе. Модуль — это логическая еденица продукта. Я уже молчу о том, что успех\падение билда этого модуля может фигурировать в каких-либо метриках команды, которая занимается этим модулем. Но как-же дебаг? Вдруг кому-то понадобится именно этой версии модуль для воспроизведения какого-то хитрого сценария?
Ну почему один и тот-же билд? Если это один и тот-же конфигурационный файл билда, но разные фазы\гоалы\профили — это по вашему один и тот же билд?
Это не мусор, это билд N#100500 модуля foobar. С тем же успехом можно говорить, я собираю продукт для релиза, зачем мне его собирать каждый час\каждую ночь — мусор в дженкинсе, в репозитории итд.
Чего мне делать с джаром backend-а?
Ничего. Он успешен. Занавес, всем спасибо, все свободны. Продолжаем итерацию\спринт или что у вас там.
Вообще-то это менеджеры заставляют меня писать такие адские костыли. Они считают, что повторный validation pom.xml — это часть нового билда. Была бы моя воля, я бы не писал такие адские костыли, а сделал так, как предлагает Borz. Это и есть настоящее правильное решение.
О, поздравляю, именно такую задачу я и решал недавно, генерируя xml в target, потом его оттуда читая и используя deploy-file. Пришлось. Но по хорошему, да, это не maven way в корне. Модули проекта должны быть самостоятельны. Неудачная сборка кого-го то одного модуля не должна препятствовать деплю остальных успешных модулей.
Deploy конечно в таком случае не запустит сборку заного, но некоторые фазы все таки будут выполнены повторно.
Ну так все правильно сделано. В чем вопрос то был? В мавене точно так же можно все поломать, если сильно захотеть. Но это не ЯП, не так искушает.

Information

Rating
Does not participate
Location
Одесса, Одесская обл., Украина
Date of birth
Registered
Activity