RI
Мне кажется прекрасный результат
Size: a a a
2020 October 08
MZ
Ну вот сравнить теслу и жигу, и сказать что тесла в пять раз быстрее, ну так понятно же там электодвигатель)
скорее так - теслу сбросить с высоты пары десятков километров и сравнивать её скорость полёта со скоростью жиги, которая едет в гору :) как по мне, жига летела бы примерно с такой же скоростью, ну с поправкой на динамическое сопротивление. проблема в том, что это сравнение не отвечает на главный вопрос - обгонит ли тесла жигу при езде в гору
RI
Главное что если я сейчас захочу собрать spring boot локально, это займет у меня 3 минуты, а не 20 как раньше
Вот 🙂
MZ
Главное что если я сейчас захочу собрать spring boot локально, это займет у меня 3 минуты, а не 20 как раньше
это безусловно ценно. но с локальной сборкой у меня и сейчас проблем нет
RI
Я могу просто посоветовать попробовать сделать параллельно gradle файлы, с помощью gradle init (он много чего автоматом подтянет) и сравнить
Ну ответ про CI
MZ
то есть, есть ощущение, что жига падает с такой же скоростью и электродвигатель не решает
MZ
Я могу просто посоветовать попробовать сделать параллельно gradle файлы, с помощью gradle init (он много чего автоматом подтянет) и сравнить
ох. для нашего проекта это будет весьма не просто, так как используется бешенное количество всяких плагинов, в том числе довольно экзотических.
прежде чем пускаться во все тяжкие, хотелось бы убедится, что эта дорога длинной в полгода закончится счастьем.
но вы меня надоумили - можно попробовать сравнить сборку spring до перехода и после в честных условиях
прежде чем пускаться во все тяжкие, хотелось бы убедится, что эта дорога длинной в полгода закончится счастьем.
но вы меня надоумили - можно попробовать сравнить сборку spring до перехода и после в честных условиях
AN
Maxim Zinchenko
В maven тоже можно было бы использовать что-то вроде build cache, если сохранять target или его часть между сборками и не делать clean. Возможно это хороший выход, но страшновато впороться в какие-то сайд-эффекты в CI. Локально-то я вообще редко использую maven для сборки, IDEA сама за всем следит и компилит почти всегда шустро.
Меня смущает именно то, что мнения о компиляции kotlin у разных команд разные. У нас вот совершенно негативное впечатление, а кто-то считает, что сборка kotlin не особо отличается от java. Наверняка есть какое-то объяснение, так как у нас разница в скорости на порядок, а такое невозможно списать на погрешность измерения. Вот по scala, например, все вроде единодушны в том, что она компилится ужасно медленно, поэтому никаких вопросов нет
Меня смущает именно то, что мнения о компиляции kotlin у разных команд разные. У нас вот совершенно негативное впечатление, а кто-то считает, что сборка kotlin не особо отличается от java. Наверняка есть какое-то объяснение, так как у нас разница в скорости на порядок, а такое невозможно списать на погрешность измерения. Вот по scala, например, все вроде единодушны в том, что она компилится ужасно медленно, поэтому никаких вопросов нет
Ну я на днях замерял. С нуля до бандла минута в проекте на несколько модулей. Где тут дальше-то экономить. Compile avoidance есть, так что ненужные модули не перекомпилируются
2020 October 11
AN
All recruiting is done in @kotlin_jobs. Paid job offers are not done here.
SR
All recruiting is done in @kotlin_jobs. Paid job offers are not done here.
Ok. Thank you
AN
Ok. Thank you
You are welcome. Open source offers are OK (most of the time), but we have policy of all paid offers going through the appropriate form and review.
SR
You are welcome. Open source offers are OK (most of the time), but we have policy of all paid offers going through the appropriate form and review.
Since I work remotely with people, I thought it would be okay to offer me a job here.
Anyway, thanks for your guidance
Anyway, thanks for your guidance
AN
Since I work remotely with people, I thought it would be okay to offer me a job here.
Anyway, thanks for your guidance
Anyway, thanks for your guidance
Well, job offers are promotions, so if you want to post them here, you will have to pay for them at least.
2020 October 12
VS
Maxim Zinchenko
ох. для нашего проекта это будет весьма не просто, так как используется бешенное количество всяких плагинов, в том числе довольно экзотических.
прежде чем пускаться во все тяжкие, хотелось бы убедится, что эта дорога длинной в полгода закончится счастьем.
но вы меня надоумили - можно попробовать сравнить сборку spring до перехода и после в честных условиях
прежде чем пускаться во все тяжкие, хотелось бы убедится, что эта дорога длинной в полгода закончится счастьем.
но вы меня надоумили - можно попробовать сравнить сборку spring до перехода и после в честных условиях
Может быть ещё неочевидная сторона вопроса: в сложных сборках на Maven часто сталкивался, что «для нормального импорта проекта в IDEA нужно сначала сделать mvn install». Проблемы там из-за того, что какие-нибудь файлы генерируются во время сборки, и, соответственно, без них код красный.
В Gradle это можно настроить, и проект не просто импортируется сходу, но и IDEA показывает где исходники генерируемые, а где нормальные.
В Gradle это можно настроить, и проект не просто импортируется сходу, но и IDEA показывает где исходники генерируемые, а где нормальные.
Ⓢ
#вопрос Коллеги, подскажите, каким способом лучше реализовать конвейер по обработке данных.
Ⓢ
Есть набор данных с полями (a,b,c). На первом шаге обработки к ним добавляется d - то есть получаем (a,b,c,d). Шагов около 5. То есть на выходе этого конвейера я получаю набор данных с полями (a,b,c,d,e,f,g,h,i).
Ⓢ
Использовать тупли(кортежи) для этого не хотелось бы, так как поля _желательно_ именовать нормальным языком из доменной области, а не first-second и т.д.
Ⓢ
Создать один на всех класс с null пока не готов результат - это отказ от принципа не-нулябельности.
Ⓢ
Создавать для хранения результата каждого шага свой data class? Может есть ещё варианты? (И желательно, чтобы не было лишних копирований - при больших списках это накладно)