А можно доплатить за премиум доставку?

Да в следующий раз уже теперь наученный горьким опытом буду премиум брать и просить завернуть получше.

Я себе с амазона как-то привозил наушники мониторные. Доставлял UPS, так там всё было упаковано в прочную коробку раза в 4 больше чем упаковка наушников и доверху забито какими-то мягкими хлопьями, так что ей в футбол можно было играть без вреда для содержимого. Доехало за две недели из штатов и курьер заранее звонил.

так что может конкретно тебе так не повезло

Есть где-нибудь статьи на предмет однозначности декомпиляции bytecode?

Есть где-нибудь статьи на предмет однозначности декомпиляции bytecode?

Скорее всего нет, есть какие-то общие принципы. Есть какие-нибудь маны по тому как работает JVM. Но фарш обратно просто так не провернуть. Тот же котлин, его некоторые части плохо декомпиляции поддаются.

Я с котлина, там коллекторов нет, поэтому привык так писать ?

Омг, что за ложь и провокажия, в котлин, как минимум, есть toList и toMap.

привет жаваны. а кто-нибудь вкурсе о текущем состоянии Java-card оно вообще как нибудь живо? шевелится?

https://en.wikipedia.org/wiki/Java_Card

Омг, что за ложь и провокажия, в котлин, как минимум, есть toList и toMap.

Насколько я помню, возвращаемый тип того же toMap() выглядит как Map<Any, Any>. Ну, честно, выглядит не очень сексуально, но насчёт этого я все же могу ошибаться.

привет жаваны. а кто-нибудь вкурсе о текущем состоянии Java-card оно вообще как нибудь живо? шевелится?

неужели ты вписался в такой проект?

Омг, что за ложь и провокажия, в котлин, как минимум, есть toList и toMap.

+1

Насколько я помню, возвращаемый тип того же toMap() выглядит как Map<Any, Any>. Ну, честно, выглядит не очень сексуально, но насчёт этого я все же могу ошибаться.

Нет конечно же :)

неужели ты вписался в такой проект?

не, просто на одну вакансию наткнулся java card architect. вот стало любопытно

https://www.infineon.com/ от этих ребят

Насколько я помню, возвращаемый тип того же toMap() выглядит как Map<Any, Any>. Ну, честно, выглядит не очень сексуально, но насчёт этого я все же могу ошибаться.

Мне кажется Вы очень зря так плохо думаете о команде которая делает kotlin std-lib.

Мне кажется Вы очень зря так плохо думаете о команде которая делает kotlin std-lib.

Ну, да, возможно. Просто какие-то неприятные впечатления остались об использовании встроенных toMap(), toList(), я даже специально открыл сейчас тот самый код, который тогда писал, но оказалось, что там используются именно они в абсолютно адекватном виде. Ну, в общем, ввожу тут людей в заблуждение :) Энивей, если речь идет о мутабельных коллекциях, в которые нужно добавить данные - я не вижу других путей, кроме как .peek() или .forEach()

не-а, все ж не резолвятся. Пробил в качестве значения константу sbt-nelyubin-sv работает, а %teamcity.build.triggeredBy.username% не стартует.

но мне нужно динамическое значение, а не константа

если посмотреть на список параметров, которые фиксируются при запуске билда (когда запускал вручную без AgentRequirements) то там есть оба параметра с одинаковым значением

@fundamentalparticle прокомментируешь?

@fundamentalparticle прокомментируешь?

кратко опиши проблему плз, я чат запарюсь перечитывать иначе

%teamcity.build.triggeredBy.username% не подменяется в каких то случаях?

Всем привет! Вопрос: в TeamCity можно настроить в конфигурации сборки Agent Requirements. Тогда эта конфигурация сборки будет запускаться только на совместимых агентах. А есть ли возможность настроить так, чтобы одна и та же сборка запускалась на разных агентах в зависимости от того кто залогинен в TeamCity? Возможно как-то с помощью параметра teamcity.build.triggeredBy.username ?

взлетит если например добавить в Agent Requirements / Explicit Requirements такое ?:

вопрос стал понятнее или еще другими словами описать?

есть одна конфигурация сборки. мне надо чтобы если на кнопку Run нажал Иванов, то сборка запустиласть на агенте с именем jvm ivanov, а если нажал Петров, то на агенте с именем jvm = petrov

возможно я изобретаю велосипед и это можно как-то сделать элегантнее

вопрос понятен

а сборка запускается только вручную чтоль?

да, эта сборка предназначена для запуска только вручную

говорят, так сделать нельзя.

ок. принято

@snelyubin мне лично самому интересно, а зачем это?

для какой то воспроизводимости?

есть некий multi-project, процесс сборки которого сильно не тривиален. создал дерево конфигураций для управления процессом его сборки в TC. предполагаю это решение предложить коллегам, чтобы меньше огребать проблем со сборкой проектов локально на dev машинах.

все синхронизируется в git

и это очень удобно

новичок с нуля мог бы собрать весь этот зоопарк просто установив агента к себе на бланковую машину

отличие от обычного CI процесса, что это получаются такие managed workcopies

это в двух словах ?

Ну, да, возможно. Просто какие-то неприятные впечатления остались об использовании встроенных toMap(), toList(), я даже специально открыл сейчас тот самый код, который тогда писал, но оказалось, что там используются именно они в абсолютно адекватном виде. Ну, в общем, ввожу тут людей в заблуждение :) Энивей, если речь идет о мутабельных коллекциях, в которые нужно добавить данные - я не вижу других путей, кроме как .peek() или .forEach()

peek -исключительно отладочная функция, использовать её имеет смысл только для распечатки того что в сриме происходит. В мутабельные коллекции можно добавлять функцией addAll или toCollection для котлин есть прям такая функция https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/to-collection.html в джавке есть Collectors.toCollection() (или как-то он называется)

это в двух словах ?

то есть чтобы пользователь через сервер запускал бы сборку у себя на компьютере?

да, чтобы она практически гарантированно собралась у него

новичку полчаса/час на сборку - и в бой ?

новичку полчаса/час на сборку - и в бой ?

так па почему без тимсити эту сборку не запустить у себя? сложная?

да, сложная, много зависимостей в частях

даже не в первичной сборке проблема, а потом при разработке

где-то забыл какую-нить градл таску запустить в цепочке - и все, опять пересборка на полчаса/час

хочется стабильности и воспроизводимости

теоретически все это можно сделать в некоем общем градл скрипте

но с TC удобнее - визуально видно build chain

логи сборки хранятся и можно бросить ссылку коллеге на ошибку сборки

теоретически все это можно сделать в некоем общем градл скрипте

Я вообще дилетант в вопросах сборки, но мне как раз это кажется в разы более прямым и оптимальным решением. Не?

Именно с точки зрения назначения инструментария.

статистика времени сборки - можно выявить узкие места в фазах сборки

вобщем плюсов много

Можно вопрос по хибернейту задать? В Oracle можно максимум 1000 параметров в in(...) использовать. Я, из-за этого, любые места с in(...) обязан обкладывать разбиением List-в. Может, это можно как-то автоматически делать? Средствами хибернейта.. Я пробовал нагуглить... нашел лишь этот кусок в коде хибернейта: int inExprLimit = dialect.getInExpressionCountLimit(); if (inExprLimit > 0 && bindValues.size() > inExprLimit) { log.tooManyInExpressions(dialect.getClass().getName(), inExprLimit, sourceParam.getName(), bindValues.size()); } Печально как-то. Надеюсь, что я просто не туда смотрю. Кто как делает в таких случаях?

Я вообще дилетант в вопросах сборки, но мне как раз это кажется в разы более прямым и оптимальным решением. Не?

ну вобщем то да. я бы на таком проекте ратовал бы за то чтобы причесать саму сборку проекта нежли полагаться на внешний сервер. С другой стороны - логи сборки и возможность некой коммандной работы - это уже либо самому что-то пилить, либо воспользоваться готовым вариантом. Но причесать скрипт сборки стоило бы по-любому, безотносительно выгоды использования ТС

Я просто представляю себя - придя на новый проект, читаю инструкции: "сначала установите себе агент ТС для сборки...". Я бы сразу (╯°□°）╯︵ ┻━┻

можно написать gradle таски, которые под капотом будут запускать TC конфиги

зато управляемость сборкой в едином месте - это прекрасно

а то сейчас 200+ разрабов на проекте и кто в лес кто по дрова

плюсом это ж все не ограничивается dev стендами

test stage например

зачем таскам запускать ТС конфиги? Может просто пускай таски делают всё локально. Просто чтоб локально отполированая сборка была. Когда нет отполированой сборки и получается дремучий лес из дров и палок с костылями

она отполирована в рамках одного проекта, но в целом это muilti-project

это тогда надо полировать новый единый градл скрипт

по мне легче отполировать TC

Так сделать "мастер"-сборку, которая будет этот мультипроект собирать, как надо, да. Будь то градл или средства уровня ОС (типа шеллскрипта, не дай боже, конечно, но вдруг).

как и писал выше - можно и так

но я явно вижу плюшки в TC, которых точно нет в чистом gradle скрипте

Это просто более разумное и корректное решение, чем костылять к этому ТС, судя по всему

Логгинг можно и в грэйдле настроить

логгинг - куда? в elastic ?

тоже вариант

но в TC не только логгинг

Ну это понятно

потом накручивать grafana к эластику - зачем если в TC это из коробки?

не вижу концептуальной разницы в сборке кончного артифакта и в сборке dev стенда

в первом случае - исходники это просто некий срез на момент X

во втором - текущий workcopy dir

Разумно получить плюшки ТС поверх отполированой сборки без ТС. Это было бы идиально. И с точки зрения человека входящего в проект ("Checkout, open, build" - ничего дополнительно не настраивать чтоб), и с моей т.к. мне приятно что от ТС есть плюшки ?

peek -исключительно отладочная функция, использовать её имеет смысл только для распечатки того что в сриме происходит. В мутабельные коллекции можно добавлять функцией addAll или toCollection для котлин есть прям такая функция https://kotlinlang.org/api/latest/jvm/stdlib/kotlin.collections/to-collection.html в джавке есть Collectors.toCollection() (или как-то он называется)

Ну, это уже придирки. Есть много случаев, когда разработчику не нужно изменять тип стрима (читай, создавать новый), а только провести над элементами действия, т.е. map оказывается недостаточно выразителен и к тому же производит оверхед. Ну, простейший пример - стрим строк, во всех нужно заменить символ ';' на ','. peek по своему дизайну идеально подходит и к тому же вернет тот же стрим, а map добавит конвейерного мусора.

Ну, это уже придирки. Есть много случаев, когда разработчику не нужно изменять тип стрима (читай, создавать новый), а только провести над элементами действия, т.е. map оказывается недостаточно выразителен и к тому же производит оверхед. Ну, простейший пример - стрим строк, во всех нужно заменить символ ';' на ','. peek по своему дизайну идеально подходит и к тому же вернет тот же стрим, а map добавит конвейерного мусора.

а там не вьюхи?

а там не вьюхи?

м?

м?

про расходы на мап

Я только что с jmh тестил, там трули оверхеды

ты что-то путаешь, это же core kotlin collections team, они не могли так накосячить

а, да нет, я сейчас про джавовские стримы

В котлиновских peek-а вообще вроде нет

Ну, по-крайней мере в коллекциях точно