🆕 Новые фичи:
— Супер-код: пишите код до super(); и this();. 💻
— Стрим-вечеринка: добавляйте свои собственные промежуточные операции, например, batch(). 🎊
— Запускайте Java как питона - в одну команду, без компиляции, даже если файлов море! 🐍
🔄 Обновления:
— Документация врубает короткую входную точку (void main() {}), заменяя неназванные классы на неявные - и это официально! 📄
— Встроенный кастрированный ASM, который ускорил сборщик мусора и освободил Java от зависимости от этой библиотеки. 🛠️
— Форейн функшен вылетает из превью, а Вальхалла уже вполне скоро будет на виду. 🌋
🔍 Изменения существующего:
— Обновлены шаблоны строк, переменные в лямбдах через _, структурированная многопоточность/скопед значения и вектор API - они прокачались, но остаются в превью/инкубаторе. 🎈
Вики по вкатыванию в джаву: https://github.com/java2ch/java-thread/wiki
Предыдущий: >>3096681 (OP)
Шапку треда писал ДимСаул?
>Java 22
Уже 5 по счету компания пишет жава 22, а на собесе выясняется, что там JVM 22, а синтаксис до сих пор используется java 8 или максимум java 11, лул
До сих пор этот подход работает. В чём я не прав? Почему это сломается как только понадобиться сделать микросервисы? Нахуя нужны монго дб, спринг даты и прочий т.н. энтерпрайз кал если такой примитивный подход работает в т.ч. в энтерпрайз задачах и даже обеспечивает нихуёвый перформанс?
У меня тоже B2B калопровод на 0.00005 RPS, сижу судорожно изучаю кафку и изоляции транзакций, но не понимаю кому это может при-го-дит-ся, где...
@SneakyThrows это костыль, которым контрят легасно помойное апи с чекедами.
>>применяю паттерн реставратор для организации работы с базами данных
Это когда из бэкапов что то выковыриваешь что ли? Никогда не слышал о таком.
Ну и смысл твоего высера? Как он хоть что-то мной сказанное опровергает, даже если бы был правдивым?
ЗП нет, технику отбирают при входе в здание, ставят за станок.
А применяю паттерн "калопровод" для управления обменом сообщениями между элементами распределенных систем
всё так
впрочем даже в Spring 6 дохуя таких мест с чекедами
Нет, стек это абстрактная структура данных. Просто потоки используют её, в основном, таким образом.
https://pkolaczk.github.io/overhead-of-optional/
Benchmark Mode Cnt Score Error Units
OptionalVsNull.sumNulls avgt 10 108,044 ? 0,102 us/op
OptionalVsNull.sumOptional avgt 10 108,042 ? 0,187 us/op
OptionalVsNull.sumSimple avgt 10 107,976 ? 0,071 us/op
Спринг бут приложение на локалхосте можно запустить без интернета?
Кек.
Ты просто не сталкивался еще со смешным пранком, где тебе надо сделать оверлодинг метода с опшеналом.
>>3117083
А, я перепутал оверлоадинг и думал про оверрайд. Ну да, забавный пранк. Только опшионал не для того, чтобы его в параметры методы ставить, он для ретурнов.
Через mvn spring-boot:run можно же будет запустить со всеми зависимостями? Сори за долбоёбские вопросы, я студентота.
>Только опшионал не для того, чтобы его в параметры методы ставить, он для ретурнов.
Он для чего угодно, не ставить его в параметры - это просто какой-то чел сказанул на SO и это возвели в ранг правила, якобы потому что это архитектурно плохой шаг, т.к. Optional сам может быть нул. То что он так же может быть нул на ретурне почему-то никто не вспоминает
чо блять
создаеш тег в битбакете с мастера
запускается пайплайн
в пайплайне девопс наговнякал mvn clean package; mv target/repo.version.jar ./
толстый жарник улетает на ифт стенд
ну или сразу на пси но там должен девопс продамкать со своей уз
а в контейнере твое говно запустится командой java -Dfile.encoding=UTF-8 -Xms512m -Xmx1g -jar repo.version.jar
Я не знаю, кто там что сказал, но ставить его в параметры смысла нет совершенно никакого.
ну так тогда и в ретёрн ставить нет смысла, логика одна же
В ретёрн смысл есть, так как в реальности встречается отсутствие значений.
Если смотреть на опшеналы как на средство для null-free кодинга на говне и палках, ставить опшеналы в сигнатуры - оверкилл. Ты идеологически уже кодишь без нулей - ну так и дизайнь код блять без нулей. Пусть в сигнатуре твоих методов будут только нужные методу аргументы, а ненужные туда не суй даже как опшеналы. Всегда полагай, что аргументы твоих методов ненулевые. Если у метода есть опциональный аргумент, скорее всего его всегда можно разбить на два метода с аргументами обязательными.
А вот ретерн - это другое. Ситуации, когда метод может легально ничего не вернуть, встречаются сплошь и рядом, при этом разбить такой метод уже не всегда получится. А тем временем самые хуевые nullы возникают именно тогда, когда их возвращают из метода, нежели когда передают аргументами. Потому что в месте где такой null стрельнет, инфа из стектрейса уже не будет содержать место, где этот нуль возник.
Мимо
>Пусть в сигнатуре твоих методов будут только нужные методу аргументы, а ненужные туда не суй даже как опшеналы.
Ну это было бы просто идеально, но к сожалению не всегда получается
Всего-то нужно вернуть простой советский "";
Идея кстати при генерации заглушек реализаций методов возвращающих строку ставит автоматом возврат "" (и ещё для некоторых особых типов типо числа или опшионала свои значения, и нулл для всех остальных), вместо того чтобы выкидывать NotImplementedException() или вообще писать preventcompile;. Можно ли как-то эту хуйню отключить?
Для стринги, допустим, отбрехался. А для всех остальных мыслимых типов, включая бизнесовые сущности, сможешь придумать такой же null-заменитель?
Да я рофлил больше, бо сам уже вляпывался с npe в энтерпрайзных классиках с >1000 полей.
>В чём заключается пранк?
https://pastebin.com/uywb2GPr
>>сможешь придумать такой же null-заменитель?
создавай лист с 0-1 элементом.
Кстати Бугаенко то как раз топил за обьекты нуль-заменители, а опшеналы и полупустые листы хуесосил, если мне память не изменяет.
>Кстати Бугаенко то как раз топил за обьекты нуль-заменители
А чем нуль-заменители отличаются от опшионал эмпти? Тем что там отдельный объект на каждый тип?
Тем, что лучше годятся в роли шарика на носу клоуна Бугаенки.
Лид на проекте обезумел. Заставил всю команду писать тесты по классической (Детроитской) школе тестирования. Теперь воссоздаем весь граф объектов в тестах и пишем тесты. Старые тесты на моках все удалили, т.к. лид посчитал их хрупкими.. А как вы пишите тесты?
Не знаю, насколько это хорошо для самой задачи тестирования, но, безусловно, очень хорошо для самоконтроля для предотвращения ООП-копролитизации, когда ни одну функцию нельзя вызвать в глобальном контексте без передачи ей всего приложения в качестве параметров.
>функцию
Бля... куда ты лезешь, лол? Типичное приложение на джаве - это спринг круд из матрешки вида контроллер - сервис - репозиторий. Сервис при этом может вызывать дохуя других сервисов. Теперь дрочим new MyServiceImpl по 10 раз на тест..
Сама классическая школа тестирования утопия и говно. Работает онли на простых примерах из двух классов. В реальных энтерпрайз приложениях у тебя взаимодействие десятков классов на изи
Успокойся, дебил. Вся команда страдает из-за таких как ты. Вместо понятно мокирования, теперь нужно дрочить весь граф зависимостей и все равно втыкать говностабы. Фу, блядь..
Найс тупой анальник бахнул от того, что пришёл на сосач за поддержкой против злой мамклида, а его не поддержали, да так бахнул, что до сих пор ничего вразумительного не выдавил.
Спок, кретин.. Я не собираюсь писать тесты по чикагски и воссоздавать весь граф объектов, лол. Ты никогда не работал на крупных энтепрайз проектах. Я просто как истинный лондонец замокирую зависимости и быстро все протещу
Бессмысленное горение без единого аргумента по теме продолжается.
У меня лид буллит тех кто пишет тесты. Говорит, что это трата времени для даунят. Надо фичи писать, а не тестовый кал
джава 5 кун
Найс пидоран, сам-то он баги не фиксит и не страдает от них.
>>Старые тесты на моках все удалили, т.к. лид посчитал их хрупкими.
А классика типа не хрупкая? Точно такое же говно вид сбоку.
Либо уж в ДДД упарываться как Хориков советовал, либо сразу интеграционные пишите.
вместо .map.collect писать сразу .collect,
можно иметь getFirst/getLast раньше 21й джавы!, можно иметь коллекции примитивов, просто более компактные коллекции, иммутабельность на уровне интерфейса. Странно что я раньше нигде не видел эту либу в проектах.
Жизненно, коллеги?
А в чём проблема? Не ом же собираем в этом треде. Строку в помник добавил и всё.
Никак нахуй, пишу код, меняю ветку в дженкинсе на свою, поднимаю свой под в аргосд, тесчу быстро пробегаюсь по своему говну, кидай юайщику делать и он там баги находит. Фичи горят, инвесторы недовольны, времени нет
Двачую лида, надо либо писать компонентные/интеграционные, либо вообще не писать.
Моки хуеки показывают что все збс - на тестовом конутре все к хуям валится при первом же вызове. Оказывается в моки подсунули данные только для хэппи паса. Забыли что там бывают нулы и некорректные данные. А потом прилетает изменение фичи - и все тесты ломаются, половина времени уходит на их переписывание.
Так это хуёвые тесты и написаны на отъебись.
Недостаточно в тикете описывать только фичу. Надо указывать список тестов.
Не, всё норм https://medium.com/@goldbal/eclipse-collections-json-serialization-support-cd3c791d2046
Ты только что Котлин.
map без stream череват, тем что он создает копию коллекции, и если у тебя серия map/filter/map/filter то у тебя будет ебовейший расход памяти на больших коллекциях
Это всё полумера. Надо иметь поддержку экстеншен методов со стороны языка чтобы их так же легко было испортировать как просто класс, чтобы прям в идею был табкомплит этих экстеншен методов и предложение табкомплита. Вот это решение.
>>3118657
> map без stream череват
Это тоже полумера, необходимо иметь поддержку implicit calls со стороны языка, чтобы list.map(mapperFunction) неявно разворачивалось чётко заданным в List (в т.ч. экстеншен методами) образом в list.stream().map(mapperFunction).toList().
>Ты только что Котлин.
Не везде ты можешь притащить Котлин. У меня контора решила унифицироваться на джаве.
>Это всё полумера. Надо иметь поддержку экстеншен методов со стороны языка
С учетом того, что экстеншн методов не предвидится в джаве, я пожалуй возьму такую полумеру!
Плюс к тому примитивы и коллекции примитивов в котлине невозможны, а это перформанс
Сама архитектура Java давно устарела. Виртуальная машина со сборкой мусора должна быть проще и не основываться на архитектуре фон Неймана, не должна подражать языкам C и C++, придуманным для низкоуровневого программирования.
Да вроде наоборот всё очень хорошо на низком уровне. Джаве не хватает сахара.
>А классика типа не хрупкая?
Нет, т.к. классика не использует моки и стабы, а только реальные классы приложения. Минусы такого подхода - нужно вручную инициализировать весь граф зависимостей. В типичном спринг приложении у тебя при попытке протестировать сервисный класс, нужно будет инициализировать 3-4 зависимости от которых зависит твой сервисный класс, а потом у каждого из этих классов может быть еще по 3-5 зависимостей, а у них еще по 3-5 зависимостей...
А лондонская школа ничего не тестирует и тесты суперхрупкие, т.к. ты просто затыкаешь все моками, которые потом будут падать при первом же рефакторинге
>у тебя будет ебовейший расход памяти на больших коллекциях
Почитай обоснование методов в библиотеке коллекций котла и почему там так решили сделать. В 99.9999% случаев ты оперируешь небольшими коллекциями и дрочь со стримами ничего не дает. В котле есть сиквенсы сиречь стримы из джавы. Ну и то, что ты где-то у себя в джава коде обрабатываешь большие коллекции уже говорит о том, что ты пишешь лютый говнокод. Т.е. либо у тебя изначально стримы, либо ты написал говно и все тащишь в память
>она послужит хорошим индикатором того, что что-то сломалось.
Нет, не послужит. Это лишь индикатор того, что ты используешь типичную лондонскую школу тестирования и обмазываешься каким-нибудь мокито. Это не проблема конкретной библиотеки, а проблема подхода. Там нельзя иначе. Ты подсовываешь мок и обрубаешь граф объектов, а потом дрочишь when thenreturn и т.д. При малейшем рефакторинге у тебя все посыпется как карточный домик. Ну и вишенка на торте (это ключевой момент, кста) - тесты твои говно-говна, т.к. тестируют внутреннее поведение, а не контракт. Т.е. ты литерально описываешь свою реализацию метода только в тесте и там видно, что твой код вызывает определенные методы зависимостей и т.д.
Речь не про это. Если у тебя хэллоуворлд на три класса, то это кэл, чел.. Тут суровый энтерпрайз на спринге, где граф зависимостей какого-нибудь сервисного класса может содержать в себе по 15-20 других классов изи. Если писать по классике, то нельзя юзать моки - онли собственные классы
>Двачую лида, надо либо писать компонентные/интеграционные, либо вообще не писать.
Работает на легких приложениях или микросервисах. Да и то, время не сравнимо если сравнивать с юнит тестами. Никто не будет ждать часы пока все тесты пробегут
>Моки хуеки
Это легаси и от него отказываются. Моки сейчас дурной тон и от библиотек типа мокито отказываются, т.к. они плодят хрупкие тесты. Кроме того ты буквально тестируешь внутренне поведение, а не контракт, когда описываешь для мока какого-нибудь репозитория кейс, а потом этот мок дергает твой сервисный класс
Нет, не так. Дело не в количестве тестов, а в их качестве. Тесты на моках - хрупкие. Тесты написанные по классике - устойчивые к рефакторингу. Но их писать значительно дольше
>Надо фичи писать, а не тестовый кал
У меня на проекте все точно так же. Катим фитчи без тестов, потом ручники месяц собирают баги, мы их кое как фиксим и выкатываем на бой. Затем уже клиенты начинают рвать анус от количества багов и мы их фиксим по ночам и в выходные
То есть вы один раз сэкономили месяц на предварительном написании тестов, и теперь каждый раз с каждой новой фичей ваши клиенты рвут жопу. Ясн.
>Мокито можно легко использовать и в классической школе
Нет, нельзя. В мокито ты описываешь конкретные вызовы методов и конкретные возвращаемые значения. В классике ты передаешь реальный объект класса со всей внутренней хурмой. В этом и отличие
> и конкретные возвращаемые значения
Олигофрен, ты никогда не задумывался над тем, что значение может возвращаться в поля объекта, а сам метод может быть void?
>на предварительном написании тестов
Не работает, если ты пишешь код по лондонской школе с моками. Тесты хрупкие и не учитывают реального поведения зависимости
Ты хуйню пишешь. Очевидно, что ты никогда не писал тесты на моках. Спокуху оформи, долбаеб. Значение у него в поле объекта возвращается, лол. Даун, у тебя классический кейс, это замокать метод, который возвращает значение
Очевидно, что
>>3118798
>значение может возвращаться в поля объекта, а сам метод может быть void
это типичный пример говнокода, который никогда не пройдет ревью. Ты хотя бы думал перед тем как это написать? Сейчас бы строить все приложение на подобных методах с сайдэффектами, лал
Ну то есть теперь уже не нисущитсвуит врёёёти, а гавнакооодд рррррря. Логгинг у тебя тоже говнокод, да, срыг инженер?
Ну и плюс докинь, петушок, каким образом то что это в твоём манямирке говнокод опровергает что-то по теме и доказывает, что метод всегда и только возвращает значение.
Это ничего не меняет. Мокая даже воид методы, ты все равно пишешь по лондону и в конце это все равно приводит к хрупким тестам, которые нужно переписывать после каждого рефакторинга или добавления новой фитчи
>ЯСКООООООООООЗАААААЛ!!!!!!!!!!!!!!!!!!
Может аргументацию какую-то притащишь?
Тебе серьезно нужно объяснить почему моки и библиотеки для мокирования плодят хрупкие тесты? Сириоусли? Или ты курсовой вкатун и волчара?
Да, объясняй. Потому что у меня за всё время использования мокито ничего хрупкого не получилось.
>ничего хрупкого не получилось
Ты никогда не писал реальные приложения. Неужели так сложно понять, что когда ты мокаешь методы зависимостей, то у тебя протекают абстракции и детали реализации тестируемого метода класса? Т.е. ты буквально повторно описываешь логику метода, но уже в тестах через моки. Тогда как в классической школе, ты подсовываешь реальный объект зависимости и просто тестируешь нужный метод. Т.е. ты не видишь, какие методы он вызывает у зависимостей, а только проверяешь конечный результат - возвращаемое значение.
В случае сайд эффектов ты можешь подсмотреть в зависимость т.к. она реальная, а не мок. В этом плюс классческой школы тестирования. А моками ты просто пишешь хрупкое говно и у тебя в тестах все разваливается. Смотри, для тупых -
Dependency dep = new Dependency();
ClassUnderTest cut = new ClassUnderTest(dep);
var result = cut.method();
// assert
или в дроченном мок стиле лондона -
Dependency dep = mock(Dependency.class);
ClassUnderTest cut = new ClassUnderTest(dep);
when(dep.someMethod(any())).thenReturn(...);
var result = cut.method();
//assert
Первый выдержит рефакторинг, если поменяется внутренняя реализация ClassUnderTest и контракт методов Dependecy. Второй - нет
Дегенерат высрал портянку теста, но по заветам лондонской школы просто повторил уже написанное. Кто заставляет внутреннюю логику метода повторять, олень?
> В случае сайд эффектов ты можешь подсмотреть в зависимость т.к. она реальная, а не мок.
Так и в мок тоже можно подсмотреть, ёпта. Никогда не задумывался над тем почему any() не сделан по-дефолту? Потому что правильный юз-кейс это проверять, что было передано туда.
> Dependency dep = new Dependency();
> ClassUnderTest cut = new ClassUnderTest(dep);
> var result = cut.method();
> Dependency dep = mock(Dependency.class);
> ClassUnderTest cut = new ClassUnderTest(dep);
> when(dep.someMethod(any())).thenReturn(...);
> var result = cut.method();
Ты похоже вообще не понимаешь задачу мокито. Если так просто инстанциировать Dependency бы было, никто бы не мокал. Мок нужен тогда когда для создания Dependency ты создаёшь ещё миллиард других объектов (в том числе тот случай когда ты вообще не можешь создать это из-за взаимодействия с копролит-апи на статиках).
Тогда говори, что не пишешь юниты, а пишешь e2e по спекам от кабана.
мимо
>Кто заставляет внутреннюю логику метода повторять
Тесты на моках это и делают. Ты должен замокать методы зависимостей, которые дергает твой тестируемый класс. Иначе это не будет работать. А в классической школе ты не должен мокать и вытаскивать внутрянку зависимостей в тесты. Либо ты просто тупой, чел.. сорян..
То есть ты должен повторить код потому что ты должен. Ясно, слив.
> Если так просто инстанциировать
Боже... какой же ты тупой, блядь... Ну ясен-красен, что это просто пример. У твоего dependency может быть 100500 зависимостей. Сути дела не меняет - ты в тесте описываешь моки методов, которые дергает твой тестируемый класс и это приводит к протекающим абстракциям
Бля, ты реально тупой? На моках ты по другому не можешь сделать, даун. У тебя тестируемый класс дергает определенные методы зависимости. Ты должен эти методы явно замокать в твоем тесте, чтобы тест прошел. Это подход лондона. В классике ты не используешь моки и просто передаешь зависимость как есть.
Так каким образом это приводит ты когда-нибудь расскажешь?
Хуита.
Во-первых, твой граф зависимостей в итоге упрётся в БД. Специальную тестовую БД делать для каждого теста? А ведь её ещё надо предзаполнить. В итоге это уже интеграционный тест получается, если не функциональный.
Во-вторых, при рефакторинге эти тесты тоже поломаются, граф зависимостей же изменится.
В-третьих, тесты с моками ломаются не так часто, если а) замокано общее поведение, а не специфичное и б) код сам по себе нормально написан.
У тестирования методов есть одна серьёзная проблема - не тестируются места на стыке методов. Если у тебя результат работы метода А передаётся в метод Б, то как ты их сам не затестируй, если А выдаёт данные в одном формате, а Б принимает в другом, то ты это никак не поймаешь. Это частично лечится только более жёстким ограничением типа возврата/параметра. Например, вместо инта передавать уинт, вместо строки enum или распарсивать в какой-то объект и.т.д., в каждом конкретном случае своё.
Ну ладно, тейк про реимплементацию зависимостей принят, я понял, о чём ты. Я про другое. Я про чтение того что класс делает с помощью моков.
У тебя в тесте явно описаны замоканые методы и их поведение, которые дергает твой тестируемый класс. В классике ты не мокаешь, а передаешь реальную зависимость и тестируешь онли вовзращаемое значение. Т.е. ты можешь поменять методы и их реализацию в зависимости, а тест не придется рефакторить, т.к. ты ничего не мокал и даже после смены контракта зависимостей все будет работать. В лондоне же ты мокаешь вызовы методов и при изменении контракта у тебя все в жопу летит
>Специальную тестовую БД делать для каждого теста?
Для этого есть фейки и стабы. Фейк - это легковесная реализация какой-нибудь зависимости. Тем более не забывай, что БД это внешняя изменяемая зависимость, а она даже в классике заменяется на фейк или стаб
> Если у тебя результат работы метода А передаётся в метод Б, то как ты их сам не затестируй, если А выдаёт данные в одном формате, а Б принимает в другом, то ты это никак не поймаешь.
Для этого надо тестировать те методы, что вызывают более низкие методы, и так до самого верха. Постепенно при подходе от юнит тестов будет движение в сторону интеграционных тестов, и это нормально.
>Двачую лида, надо либо писать компонентные/интеграционные, либо вообще не писать
Ты не понял, чел. НИКАКИЕ тесты. Писать надо только ФИЧАКОД.
Поддержу лида - зачем тесты? Чем больше багов, тем больше оплачиваемой работы. Писать тесты с фичей - это неоплачиваемая работа и претензии на перформанс ревью.
> Писать тесты с фичей - это неоплачиваемая работа
В смысле? Всё в рабочее время делается.
Платят тебе за фичу, а не за тесты фичи и ждут, что ты сделаешь две фичи за отрезок времени, а не одну фичу и тесты. Васек, который рядом только пилит фичи, получит 5 за перформанс и премию х2 к твоей, а потом все баги закроет отдельными тасками и получит персональную премию от кабанчика.
База коммерческой разработки.
>кабанчик-долбоёб спонсирует багодел
Опять же это вопрос не к тому полезно ли для разработки тесты писать, а к тупости кабанчика. Это немного разные вещи. Первый технический, второй в мвп или в б.
За ci, контроль версий и ревью тоже заказчик не платит. Можно не тратить на это время и сразу деплоить в прод.
Анальник, который выучил апи мокито (который в процедурном стиле на флюент инглише, чтобы даже макака разобралась) считает, что он то умный, а кабан дурак. Классика.
Сразу на проде редактировать, компилировать, чо как маленький? Если коллега одновременно с тобой отредактировал тот же файл, надо написать на него жалобу, что он твою недельную работу похерил.
Отношения: company-employee one-to-many, company-office one-to-many.
Представим, что в таблице company у нас 100 записей, в таблице employee 100 000 записей, в таблице office 1000 записей.
Вопрос:
1) Как в hibernate эффективнее всего настроить мэппинги?
2) Если у нас стоит задача вытянуть все данные, как бы мы построили эффективнее всего вопрос?
Спасибо за мнения. А ещё может кто-то знает годные книги по персистентности в джаве, и может порекомендовать — буду очень благодарен.
Эффективнее всего, внезапно, писать sql руками и смотреть планы запросов. Хуебернейт за тебя не напишет.
>задача вытянуть все данные
Что значит все данные? SELECT * FROM table? Сделай три параллельных запроса, по одному на таблицу.
>1) Как в hibernate эффективнее всего настроить мэппинги?
Никак. Надо ливать с легаси проекта. Сейчас бы в 2к24 хубирнейт использовать..
То-то в суперпостооп языке го такая же сборка мусора и все круто.
Котлин же решил эту проблему через инлайн инстанса Class<T>, гугл решил через TypeToken, из отдельный язык сможет
Был бы я мухой, я бы не предлагал развивать джаву, я бы сидел и обмазывался гетсетами.
В прошлом треде анти-хибернейтовские вскукареки так и не выдвинули ни одного нормального аргумента или альтернативы для "2к24"
>Эффективнее всего, внезапно, писать sql руками и смотреть планы запросов. Хуебернейт за тебя не напишет.
Как бы ты написал?
Если ты беспокоишься об эффективности - пиши вручную запрос на аннотациях и отображай во проекции. Хибер достаточно криво делает запросы через иерархию, с кучей под запросов.
Что тут имеется ввиду?
>Это тоже полумера, необходимо иметь поддержку implicit calls со стороны языка, чтобы list.map(mapperFunction) неявно разворачивалось чётко заданным в List (в т.ч. экстеншен методами) образом в list.stream().map(mapperFunction).toList().
В скале были имплицитные параметры, наелись и сильно ограничили.
>>3118788
>Ну и то, что ты где-то у себя в джава коде обрабатываешь большие коллекции уже говорит о том, что ты пишешь лютый говнокод. Т.е. либо у тебя изначально стримы, либо ты написал говно и все тащишь в память
Вас посетил Марти Фаулер, чистота кода удвоилась.
Тогда рекомендую посмотреть Eclipse collections, они как раз оптимизированные по перформансу
Если у вас так много багов то это либо ебать какая сложная система, либо у вас волчья стая с годом опыта на всех вместо разрабов.
>>ручники месяц собирают баги
Ну и процессы говно, они должны их сразу отдавать а не копить под релиз.
>>время не сравнимо если сравнивать с юнит тестами
Интеграционнные писать долго, но они редко меняются - для этого должна произойти смена контракта.
Юниты пишутся быстро, но меняются каждый раз при каждом изменении. Даже если просто сигнатуру метода где то сменили - надо и про тесты не забыть.
Для утилитных методов - они ок, для калопроводов - не подходят.
>>говно лучше чем моча
Читай пикрелейтед.
Двачую. Пишу юниты в спринг калопроводах только на утил методы и на костюмные валидаторы.
>>Васек, который рядом только пилит фичи, получит 5 за перформанс и премию х2 к твоей
Это уже от процессов зависит. Будь у меня помойка с КПИ я б тоже наверное забил бы на качество в угоду скорости...
Но у меня фикс зп и похуй как долго я делаю фичу, если я смогу обосновать что ТАК НАДО.
>>анти-хибернейт
>>так и не выдвинули ни одного нормального аргумента или альтернативы для "2к24"
>>3100236 →
>>3100590 →
>>3101720 →
Там была целая ветка про жук, ты все пропустил
Сам его используй, но я хибером мало пользовался не могу однозначно сказать что удобнее.
>для калопроводов - не подходят
Кто же виноват, что ты пишешь говнокод, который невозможно протестировать кроме как интеграционными тестами, которые можно часами гонять, лол
>Читай пикрелейтед.
Там типичная шарпомуха-говноежка, которая угорает по классической школе, но дрыщет в штаны показать пример где фигурирует больше 2 классов.
> Работает на легких приложениях или микросервисах.
Ты долбоёб? Интеграционные тесты наоборот легче писать и они гораздо более лояльны к говнокоду.
>Надо ливать с легаси проекта
>Java Thread
Я чуть кофе не подавился.
Видимо то, что при таком раскладе хибернейт на каждом взаимодействии с иерархией энтити будет проворачивать огромное количество подзапросов, чтобы подтянуть все разветвления этой иерархии. И это просадит перформанс.
Ну да, нужно ливать на го, там пишут как писали на джаве 20 лет назад, зато не джава, а значит не легаси, омномномном!
Сегодня кросс платформенное десктоп приложение на javaFX писать плохая идея? Хотя из альтернатив c++ с qt бля...
Лучше электрон js. Ещё для котлина есть KMP, но он недавно появился.
Жулик не пройдет.
Они заскакивают и на 50к ради опыта, только ничего не делают.
А делать придется тебе, потому что ты его нанял))
нанимаешь человека, платишь деньги а двойную работу делаешь ты.
ВЫШЕЛ ВЫШЕЛ ВЫШЕЛ
ВЫШЕЛ ВЫШЕЛ ВЫШЕЛ
>>3121415
> Asynchronous initialization of beans during startup
И нахуй это надо? На 10 секунд ускорит поднятие, и что?
10 это уже дохуя. Теперь го еще более не нужен станет. Правда, ЦПУ на старте еще больше будет жрать. Да просто древнющие ишы запилили. Еще одна с 2008 года сделана наконец.
Вот бы придумали способ платить человеку х0.5 первые 1-3 месяца и легально уволить его, если не перформит. Эх... но такого нет...
>Теперь го еще более не нужен станет
Если писать как на го, то он и совсем не нужен будет. public static void main и вперед. Большинство различий в сравнении этих языков в подходах к написанию программ, а не в самих языках.
>>А делать придется тебе, потому что ты его нанял))
Ну надо так надо, только количество тасок в день не изменится, мне ж за переработки не платят.
>>двойную работу делаешь ты.
А в чем сложность? ну будет 4 фичи в очереди, а не 2 - будут сделаны за 4 недели а не за 2.
На кваркус переписывать надо, а спринг вот он, версию обнови - и полетели.
>>10 это уже дохуя. Теперь го еще более не нужен станет
Если тебе надо поднимать за 0,3 секунды как в го - просто используй спринг натив с комплиляцией.
Он же еще не работает толком. Когда я последний раз пытался его на винде собрать, там куча лишних телодвижений требовалась.
Ну то что нужно куча лишних телодвижений не значит что он не работает
>10 это уже дохуя
Типичное приложение на спринге стартует +- за минуту-полторы. Твоя пердолька с "параллельной" инициализацией сэкономит ну максимум пару секунд. Именно поэтому все новые проекты пишутся исключительно на гоулэнге где сервис от момента старта до момента, когда он готов обрабатывать запросы тратит не больше 1 секунды
Разве нативность не должна ускорить разве что запуск жвм, что и так практически мгновенный? А если тут идея в том, чтобы житу не приходилось прогревать, то какой смысл в ускорении запуска за счёт жита, если скорость запуска важна только разработчику и ему всё равну ту же компиляцию придётся выполнять, просто не при запуске, а, при, собственно, компиляции.
Нуль-заменители - миф на самом деле.
Идея была - подобрать такой обьект, который по семантике как бы пустой, нулевой, но при этом это полноценный обьект с полноценным контрактом - ты можешь его передавать куда хочешь и не бояться NPE. А реальность такова, что не для каждого кейса такой нуль подобрать вообще возможно, не сломав семантику. А для каких то кейсов таких "нулевых" обьектов может быть вообще больше одного.
>Ну надо так надо, только количество тасок в день не изменится, мне ж за переработки не платят.
>А в чем сложность? ну будет 4 фичи в очереди, а не 2 - будут сделаны за 4 недели а не за 2.
Сейчас ты берешь таску и делаешь ее, переходишь к другой. Все очевидно и просто. Получаешь свои деньги.
В твоем примере будет 4 задачи вместо 2, но тебе придется ебаться, ползать по коду, устраивать созвоны, включать думалку, спрашивать, напрягать людей, анализировать логи, анализировать историю и постоянно ебаться на ровном месте и искать причины несостыковок, рыться в быдло-коде.
За это тебе никто не доплатит.
Если ты такое любишь, то к тебе тогда вообще вопросов нет. Есть много людей которые работают просто ради денег и будут делать любую грязную работу в it, лишь бы платили.
Какой смысл волку идти на нищие 50к? Наоборот, явный красный флаг, когда специалист с годом+ опыта просится на 100к в третьесортную компанию.
Волк, по определению, мимикрирует под успешный успех, а опыт рисуют, поэтому ему не нужно на галеру "за опытом", ему нужно на галеру за деньгами.
>Наоборот, явный красный флаг, когда специалист с годом+ опыта просится на 100к в третьесортную компанию
Это нормальная зарплата для человека с годом опыта. Я начинал с 15к в далеком 2012 году. Только год назад вышел на баснословные 200к
Я бы сказал, что это минимально возможная зарплата для человека с годом опыта (и надеюсь, мы говорим о 100к, а не о 50). И тогда никаких шансов, что человек будет идти на те же 100к, а забрать готового специалиста с рынка можно за 150-200, за 100к работает человек, которого вырастили и то, уже начинает смотреть по сторонам, с улицы на такие деньги никто не пойдет, кроме проблемных.
Ну и жавист с опытом 8 лет, по определению, не может зарабатывать 200к, эту планку успешные берут уже в первый год, даже без волчизма, отсталые пересекают на 3.
>>Типичное приложение на спринге стартует +- за минуту-полторы.
Зависитт от размера. Средний сервис у меня секунд 30. Но даже если там 10 минут, какая разница сервис обновит версию в 15-20 или в 15-30. Бизнесу похуй. Можно просто кнопку мержа раньше/позже нажать.
>>Именно поэтому все новые проекты пишутся исключительно на гоулэнге где сервис от момента старта до момента, когда он готов обрабатывать запросы тратит не больше 1 секунды
Таких сервисов, которые надо внезапно поднимать и потом опять тушить на дни/недели/месяцы - не так много. Это характерно для облачной структуры с наносервисами. Типичные сервисы работают всегда.
Да и то для этого есть нейтив. Запускается за секунды, но компилируется долго.
>Но даже если там 10 минут, какая разница сервис обновит версию в 15-20 или в 15-30. Бизнесу похуй. Можно просто кнопку мержа раньше/позже нажать.
Нет, не похуй. Не знаю как у вас в жаве, но у нас сервисы крутятся в кубере и гибко масштабируются. Когда у тебя уходит всего 1 секунда от старта до приема первого запроса клиента, то скэйлинг сервисов проходит по щелчку пальцев. Появилась нагрузка - кубер автоматически запустил сервисы. Нагрузка спала - потушили сервисы.
>>Ну и жавист с опытом 8 лет, по определению, не может зарабатывать 200к, эту планку успешные берут уже в первый год, даже без волчизма, отсталые пересекают на 3.
Коллега с 5 годами пока только приблизился к 200к, я с 3 тоже скорее всего не перепрыгну ее в этом году.
Но выходить из зоны комфорта тоже не хочется - удобные процессы, много свободы действий (выбираешь таки и технологии), ненапряженные условия, удаленка без какого-то контроля.
А я еще и не самый молодой и шутливый. Попал прям в ловушку скуфидона.
>Ну и жавист с опытом 8 лет, по определению, не может зарабатывать 200к, эту планку успешные берут уже в первый год, даже без волчизма, отсталые пересекают на 3.
Зачем ты лжешь? Все зарплатные вилки открыты на то же гетмутче. 200к это зарплата сеньки. Даже я пропахав 10 лет в жаве-хуяве получал максимум 200к. Сейчас свичнулся в гоулэнг с понижением грейда и зарплаты до 150к. Время сытых зарплат прошло, а пороги того же мяскота оббивают вчерашние таксисты и курьеры
Ну судя по бенчам нативные стартуют в 20 раз быстрее
https://www.baeldung.com/spring-boot-vs-quarkus
Тут наверное влияет то, что Грааль создаёт большинство объектов на компиляции, всё что статический рантайм (static {})
>>скэйлинг сервисов проходит по щелчку пальцев
Если нагрузка прям мгновенно и непредсказуемо появляется - ну ок, ебашь на спринг нейтив. Код даже переписывать не придется. Зачем искать пхпшников/гоферов и учить их писать бизнес логику ради этого?
Ну это можно чисто российский рынок, за рубежом так-то больше платят
Мы тут и обсуждает российский рынок в рублях. Зарубежка в рублях это про всякие какарачастаны - там и условиях жизни очень специфичные, обычно хуже. А зарубежка в доларах/евро - другой мир с которым нет смысла сравнивать.
Я вот хз, в моей галере, несмотря на ученический договор, где тебе платят хлебными крошками со стола кабанчика, через год минимум зарплаты - 130, через два - 180, но люди либо уходят на 200+, либо перспективным сама контора вытягивает вилку.
Если раньше это можно было списать на региональные коэффициенты, то сейчас нет никаких проблем попердывать в диван в Мухосранске и работать на ДС.
>>3121949
>>200к - сытая зарплата
Охуеть, при курсе бакса по 100р - это копейки, чтобы хватило чуть продержать до следующей подачки.
>Охуеть, при курсе бакса по 100р - это копейки, чтобы хватило чуть продержать до следующей подачки.
Таковы реалии рынка. 300к и выше получают тимлиды и рукли отделов
>Охуеть, при курсе бакса по 100р - это копейки, чтобы хватило чуть продержать до следующей подачки.
>Писать программы больше не выгодно. Российским программистам стали платить даже меньше, чем риелторам
https://www.cnews.ru/news/top/2024-04-13_sozdavat_programmy_v_rossii
Сдавай хату
В моем манямирке - 300 вполне реально достижим на 3-5 годах опыта, ну а там уже можно и трактор заводить.
Да и возвращаясь к базовому комменту - волк не будет идти на 50, да и на 100 он тоже не пойдет, если уж накручивать, то накручивать, чтобы опыт выглядел солидно, а красивое резюме требует такой же красивой зарплаты в требованиях.
Поинт в том, что таких зарплат нет
>а там уже можно и трактор заводить
Кому ты нахуй нужен, лол?
Те, кто ковыряет копролит за <200к уже лет 10, точно не нужны.
Чего мне смиряться-то? Я уже там, лол) Смирись, если хочешь)
Можно себя убеждать в чем угодно, оправдывая свое нищенское существование и отсутствие продаваемых навыков.
Еще играет важную роль возраст. 30+ - ноухайр. А какие навыки продаются?
Ну так ты в Двугапуписе или в Амстердаме, Лондоне, Берлине?
Компиляция дольше в 65 раз (на 110 секунд), зато сэкономили 1,7 секунды на запуске. Вот это прогресс!
Что не так? Конпеляция делается один раз, а запуск много.
На время запуска, когда оно меньше нескольких часов, не похуй только тогда, когда это время разработчика во время интенсивного цикла исправления и перезапуска. В таком случае комплируется и запускается примерно одинаковое количество раз.
Чел, выше уже описали для чего это конпеляция нужна - мгновенно скалировать сервисы в облаках, где за нагрузку надо платить или запускать что то редкое. Там лишние 10 секунд запуска на каждом из тысячи сервисов - это счета на многие тысячи/миллионы долларов.
Если у тебя не гугл с хайлоадом - говно без задач.
>каждом из тысячи сервисов
вопрос только нужна ли тебе тысяча сервисов или там опять микросервисное безумие
так-то и миллион сервисов можно поднять, бешеной собаке семь верст - не крюк
>я работаю на юникорна
Литералли who? Вот на этих что-ли?
https://unicorn.com/en/company-profile
Это же ноунейм галера, где нищие хохлы что-то там педалят на спринге за лоупрайс. ЕПАМ или Люкс и то солиднее в разы будут.
>What Is a Unicorn?
>The term unicorn refers to a privately held startup company with a value of over $1 billion. It is commonly used in the venture capital industry. The term was first popularized by venture capitalist Aileen Lee. Unicorns are very rare and require innovation.
Скуф
Есть какие-то библиотеки или приёмы для ускорения вычислений чисел с плавающей точкой?
В джаве оно из коробки ускорено до предела.
>>3123068
Благодаря интринсикам и жиду на джаве скорость равна си.
> Как часто вы кодите вне работы?
Ну я крайний раз гирлянду на нг погромировал и переводил мониторинг с докер компоста на системд ибо заебало. Больше не припомню.
Зависит, нужно смотреть конкретно твой код где ты считаешь эти числа.
Но стандартные приёмы - это конечно использование примитивных типов (float/double вместо Float/Double) и уменьшения использования указателей - то есть раскладывание твоил чисел (скорее всего) в массив, чтобы побольше влезло в кэш процессора.
Еще можно попробовать итерацию по этим массивам через индексированный цикл for (int i =0; ...; i++), иногда помогает, но нужно смотреть на твоём случае
>>3123224
Так же если ты в процессе вычисления очень часто вызываешь какие-то функции (скажем больше 100 раз за вычисление) - попробуй сделать их статическими, может помочь
Баланс соблюдаю, кодю иногда, но просто потому что нравится. Книги не читаю, потому что по моему опыту абстрактное знание без конкретной цели применения 1) тяжело понимается 2) быстро забывается. Если что-то понадобится для конкретной цели - могу книгу почитать.
Полностью с тобой согласен! НО, иногда без определённого теоретического знания, ты даже не будешь знать о неких возможностях.
Если такие знания и существуют, то за 10 лет нахождения в сфере и общения с коллегами я таких не встречал, но допускаю
В основном все теоретические раскладки сводились к тому, что они либо все черезмерно усложняют на практике, либо вообще убивают производительность по единственной причине "так надо делать, умные люди сказали"
>>3123224
Кстати еще добавлю про раскладку в масивы - ОДНОМЕРНЫЕ массивы - это прям идеально (но не всегда удобно). Но это уже совсем хардкор, сначала попробуй попроще оптимизации
Кстати, ЯМР-анон, этот ты?
Ещё конечно нужно использовать минимум аллокаций памяти. А это значит:
- если ты часто создаёшь какие-то объекты в процессе вычисления - старайся их создавать меньше и переиспользовать
- если работаешь с коллекциями - старайся резервировать их объем с запасом, чтобы лн гарантированно вмещал все ожидаемые данные и не расширялся по пути. Как пример для arraylist - ты ожидаешь 1000 значений - создаёшь new ArrayList(2000) на всякий случай. Для других можно что -то похожее. Для массива это просто new double [2000] (массивы быстрее очевидно)
Нищий пидорюнь, причём тут я? Не способен в мышление без проекций?
>Достаточно сказать что я работаю на юникорна, чел
Речь идёт о трехзначных суммах!
А причем здесь проекции? Ты на простой вопрос не можешь ответить?
Ну уверен у тебя-то речь идёт о больших суммах. О каких кстати?
Ты при том что ты собеседник в этом разговоре, разве это так сложно понять, скуфидзе?
Бля, реально трёхинтовый. Ну тогда ты был прав, такой скуф как ты за рубежом действительно никому не нужен.
Ты тут уже десяток постов высираешь дёшевые понты, но так и не назвал его и не пруфанул.
ждём вскукареки про диванон
>>3123070
>>3123224
>>3123228
>>3123265
>>3123311
Спасибо, мне в итоге apache math имела всё необходимое.
>Кстати, ЯМР-анон, этот ты?
Не, я в треде вообще в первый раз.
>Не, я в треде вообще в первый раз.
Как тебе у нас тут? Пожалуйста, поделись впечатлениями и поставь оценку.
> Как тебе у нас тут? Пожалуйста, поделись впечатлениями и поставь оценку.
Присаживайся, родной, сейчас добрый доктор Столяров пропишет уринотерапию.
Отстаньте вы от Димки Соловьева, ему еще с хохлами в интернетике сражаться.
Может кто то объяснить как связаны фреймы реактора в дебаге с обычными фреймами пикрил
Чего я не понимаю, так это почему, когда у меня Tomcat в Eclipse запущен, то Tomcat9w не распознаёт этого, и показывает статус "Stopped"? Это два разных Tomcat-а? Я правда запутался.
Брачо,совет,забудь про ручную установку варника на томкат,спринг бут с встроенным томкатом бвл создан как раз для того чтобы ты не страдал,а мог сосредоточиться на написании своего супер сервиса,не противься прогрессу братка,пис,джа
Я в идее томкатик запускал без проблем через плагин. Кстати, интересно, какой процент людей в этом треде сидит на эклипсе
Я не шарю в Спринг Бут (но как-раз собирался одним из следующих туториалов его пройти).
Знать как все работает под капотом это всегда полезно,но я боюсь что ты на отладку и фикс подобных приколов потратишь столько же сколько на изучение сервлетов. Работать чисто с томкатом ты не будешь никогда
>Спасибо, мне в итоге apache math имела всё необходимое.
О, спасибо кстати, хорошая либа, буду иметь в виду
Если что, я нашёл решение https://stackoverflow.com/questions/23655416/how-to-set-jvm-options-for-tomcat-instance-executed-from-eclipse
Похоже, что это всё-таки другой Tomcat, но непонятно, зачем тогда мне нужно было скачивать и устанавливать его отдельно...
Томкат кал. Ставь стеклянную рыбу. Еще трендовый JSF + Primefaces изучишь.
А в вашей жабе есть нормальный клиент для редиса? Коллега посоветовал реддисон, но там забагованное говно написанное Никиткой Cockшаковым, который у себя на гитхабе плюется желчью и брызжет слюной, когда его в очередной раз макают в его говнокод и показывают, что он не работает. Проиграл с этого озлобленного уродца, который закрывает ишьюсы со словами "все работает!", лал!
Проиграл с этого озлобленного уродца, который своими кривыми сальными ручонками не смог выполнить элементарнейшее действие — запустить реддисон, от чего побежал плакать разработчику и из-за чего был закономерно послан нахуй.
Насколько безопасно в них делать статические поля? Хочется вынести часть хуйни в методы и сократить говно мамонта раз в 10, вот только проблема в том, что основной метод статический, и все остальное придется тоже статикой делать.
%еще могу извратиться и передавать параметры из массива, а дублирующийся код в цикле крутить, но это смешно%
>Есть тут динозавры, которые работали с Java Stored Procedures в базах оракла?
Аж олдскулы свело.
>Насколько безопасно в них делать статические поля?
Что значит "безопасно"? Чего ты опасаешься?
Да что откуда-то параллельно дернется то же поле и кривые данные будут. Или там похуй, оракл не даст?
Не знаю как сейчас, но в 10 на каждую сессию создавался свой инстанс JVM. Если ты не будешь дергать процедуру из каких нибудь parallel query, то должно быть потоко-безопасно.
Но вообще, такой подход это говнокод, конечно же. Если статическая функция не имеет состояния, то и писать в статические поля она не должна. Всё должно передаваться в другие методы явно. Если параметров много: создай DTO или вынеси логику в отдельный класс и создавай новый инстанс на каждый запрос.
Ну у меня сразу 2 вопроса:
- чего общего между статическими полями и переиспользованием кода?
- почему крутить код в цикле смешно?
если тебе нужен какой-то кэш на время работы функции, то закидывать его в статическое поле по-моему еще смешнее
Потом, смотрю на определение so: A synchronization order is a total order over all of the synchronization actions of an execution.
Правильно ли я понимаю, что это про одно и тоже? И SO линейна и точка?
Литералли who? Чем знаменит, кем работает? Очередной провинциальный тимлид?
>Просто потрать несколько часов на компиляцию (которая в любой момент может отвалиться) чтобы сэкономить несколько секунд на старте
Все компилируемые так работают. Но если тебе прям пиздец как надо запускать за 0,3 секунды - терпи.
Проект на го собирается максимум за минуту с прогоном всех юнит тестов.
Почитал ченжлог - не вижу особых преимуществ, когда можно и 2 версию на 21 ждк запускать.
У тебя разве нет желания апдутить всё до последней версии просто потому что версия последняя?
Если на джаве удалить все юнит тесты кроме двух то тоже будет собираться быстро.
Это также можно реализовать в рамках существующей многопточки. Лучше жди structured concurrency.
Каким образом? Я пока что вижу только убогое распиливание на миллион подфункций, сохранение стейта ручками после завершения каждой и восстановление при запуске.
>Каким образом?
Используй прерывание, или вот такую штуку https://docs.oracle.com/cd/E17802_01/j2se/j2se/1.5.0/jcp/beta1/apidiffs/java/util/concurrent/CancellableTask.html#cancel(boolean)
Вообще без нормального тз я не понимаю в чем сложность.
>сохранение стейта ручками после завершения каждой и восстановление при запуске
Ну не надеятся жи на жидбренсов.
К слову, ответь и на мой вопросик~ >>3126939
> Используй прерывание, или вот такую штуку https://docs.oracle.com/cd/E17802_01/j2se/j2se/1.5.0/jcp/beta1/apidiffs/java/util/concurrent/CancellableTask.html#cancel(boolean)
И чем это поможет?
> Ну не надеятся жи на жидбренсов.
Я щас говорил не про фактический план действий, а про то, что хотелось бы видеть в джаве.
>И чем это поможет?
Просто обертка.
>что хотелось бы видеть в джаве.
Вообще суспенд это про вытеснительную многопоточку, в жабе кооператинвая. С последним выпиливанием суспенда из треда, мне кажется нихуя не будет сделано в этом направлении.
Сука и проигнорил мой вопрос. Ладно, в жопу этот тред.
>Очередной провинциальный тимлид?
Да, это все тот же форс хуилы с прошлых тредов.
>В чём я не прав?
В том, что пишешь говнокод.
Если у тебя есть долго работающая таска, то её надо писать так, чтобы она периодически сохраняла состояние и умела продолжать с точки последнего сохранения. От сбоев железа никто не застрахован и спускать в унитаз весь прогресс из-за отказа плашки памяти признак херовой архитектуры.
А так то, тулы для этого есть https://youtu.be/RLFQj2mPqUM?si=s6E2_CSSwQ6Zz1eQ
стейт переживающий перезагрузку сервера - это как-то выходит за рамки любого языка
>И чем это поможет?
Не нужно распиливать функции обновляешь постепенно стейт в таске, когда приходит прерывание - сохраняешь стейт, потом восстанавливаешь.
Ты долбоёб? Я именно про это и говорил. Сейчас это решается нагромождением кучи ручных говносохранений, что, очевидно, ложат перформанс в сраку, а если бы была поддержка от языка этого, это было бы гораздо легче и быстрее
> потом восстанавливаешь
И как ты это собираешься делать с одной огромной функцией? С божьей помощью?
> А так то, тулы для этого есть https://youtu.be/RLFQj2mPqUM?si=s6E2_CSSwQ6Zz1eQ
Это другое.
Да хоть id в стейт пихать, а в функции, к слову в жабе нет функций, написать switch/case. У тебя фантазии вообще нет?
> написать switch/case
И получишь кучу функций, просто запуск каждой будет ещё нагружен вычислением результата свич кейса.
>нагружен вычислением результата свич кейса
Хуйню несешь.
>И получишь кучу функций
Пиши прям в кейсе. И я не понимаю, в чем проблема множества методов, если существует инлайн?
Множество методов = бойлерплейт? Ты ебнутый?
Вроде наоборот, йобаметоды антипаттерн. Или че там, мода поменялась уже
Ты нарушение маняпаттернов и бойлерплейт не путай. Совершенно разные вещи. Бойлерплейт это когда ты пишешь объявление метода, потом в каждый метод хуяришь логику сохранения, потом при запуске выбираешь, какой метод запускать в зависимости от того, что насохранялось, и только потом пишешь свою логику.
Пиздец ты шизофреник,страшно подумать что о тебе думают твои коллеги
>Бойлерплейт это когда ты пишешь объявление метода, потом в каждый метод хуяришь логику сохранения
Дурачек, тебе уже сказали про интерапт. Можно не ебать себе мозг логикой сохранения, а просто наверх все отпускать, а там уже разберутся.
>потом при запуске выбираешь, какой метод запускать в зависимости от того, что насохранялось
Еще раз, это можно также выбирать в общем методе, который свитчкейсами. На самом деле я просто описал то, как в котлине это работает, не более. Хотя вот хз есть ли там прерываниия, но кейсы точно есть.
> Дурачек, тебе уже сказали про интерапт. Можно не ебать себе мозг логикой сохранения, а просто наверх все отпускать, а там уже разберутся.
И тебе уже ответили что получается ровно то же количество бойлерплейта, но ещё и нагрузка на обработку исключений.
> свитчкейсами.
Именно так это и работает прямо щас...
>ровно то же
Верим.
>Именно так это и работает прямо щас...
И будет работать дальше. Изменений можешь не ждать. Нытье не поможет.
Триалки регистрируй. Или ищи кряк на торрентах, но жидбрейсовое говно настолько баганое что лучше бы пользоваться последней версией.
>Я именно про это и говорил. Сейчас это решается нагромождением кучи ручных говносохранений, что, очевидно, ложат перформанс в сраку, а если бы была поддержка от языка этого, это было бы гораздо легче и быстрее.
Спокойно, мы уже поняли что ты дебил, не усукабляй.
В общем случае, контекст функции это весь рантайм и ОС, а не пара переменных на стеке. У тебя может быть переменная А, которая ссылается на Б, а Б зависит от некоторых статических переменных и при следующем запуске там могут быть другие значения. А ещё есть метод который закрыт локом и он сейчас захвачен неким тредом, и при следующем запуске тред будет другой. А ещё есть ресурсы Ос, типа открытых файлов, сокетов, сессий БД. А ещё есть всякие токены которые норовят протухнуть. И всё это должен решать язык. Раз плюнуть.
И это, мы ещё не говорим про баги в коде, которые решаются рестартом процесса.
И кто-то что-то говорил про необходимость это всё сохранять? Речь прямо шла про создание инструмента для автоматического преобразования компилятором функции в то, что можно легко приостановить и сохранить. Пускай все остальное как и раньше лежит на программисте.
Eclipse, vs code, второе сильно пофичастее и поудобнее, а сделан vs code по сути на базе технологий эклипса.
> но жидбрейсовое говно настолько баганое что лучше бы пользоваться последней версией.
Очень, скачал с рутрекера какую-то 2022 версию - она рандомно примеры с книги запускает, то не запускает. В эклипсе/vs code все работает без проблем.
Пример покажи хоть. Похоже на бред, поскольку непосредственно запускает жвм, а не поделие жидбрейнсов.
примеры Хорстмана с его сайте 10 и 11 издание. Житбрейнс брал с ру-трекера.
Там первые главы - примеры без указания package. Вот на них оно спотыкается, как минимум. С эклипсом все без проблем работало.
> а не поделие жидбрейнсов.
Эта хуета игнорировала в системе java 21 настроенные переменные PATH и качала openjdk самостоятельно. Может инструмент и неплохой, может и лучший, но по началу разбираться что к чему мне не хотелось. Опять же нормальной справки по иделии, как дока vs code я в принципе не видел. Может хуево смотрел.
>Там первые главы - примеры без указания package. Вот на них оно спотыкается, как минимум.
Ну т.е. фиксируем. Это ты запихнул некорректный код, а теперь руагешь иде, что она сама все не решила?
>Эта хуета игнорировала в системе java 21 настроенные переменные PATH и качала openjdk самостоятельно.
Ну я хз куда ты там тыкал, у меня все норм детектит. Рукожоп мб.
>как дока vs code
У мелкомягких очень хуевые доки. Типа ну там есть 100500 примеров для каких-то ситуаций, а в общем ничего не описано. Условно, там даже не написано, а где блять кнопка ран. А в примерах все через терминал. Нахуй мне тогда этот редактор собственно.
>Житбрейнс брал с ру-трекера.
Зачем? Тебе комунити не хватает? Или тебе так понравился тул, что зажал 600 евро в год?
> Это ты запихнул некорректный код, а теперь руагешь иде, что она сама все не решила?
Во прикол челику который видит первый раз java-код разбираться что-там и как в специализированном редакторе, а не изучать программирование.
> А в примерах все через терминал
Если честно - я ненавижу микрософт и это по сути главная причина почему я начал изучать java а не c#
Но ты сейчас врёшь и не краснеешь: https://code.visualstudio.com/docs/java/java-debugging#_configure
> У мелкомягких очень хуевые доки.
Буквально лучшая дока, что я видел за последние лет десять. И в редакторе и на этом сайте.
>>3128770
>>3128817
ПроцессорAMD Ryzen 5 5600H with Radeon Graphics, 3301 МГц, ядер: 6, логических процессоров: 12
16 гигов оперативы
И эта срань умудряется на этом лагать.
Спасибо, но я лучше и дальше на эклипсе и vs code поеду.
Какие у тебя задачи, что ты выбрал джаву? Судя по коду на скрине тебе шарпы подойдут больше. Ты говоришь про ненависть к майкрософту, но
1) Сидишь на их игровой прошивке вместо ОС
2) Собрался писать код в их редакторе кода
>ПроцессорAMD Ryzen 5 5600H with Radeon Graphics, 3301 МГц, ядер: 6, логических процессоров: 12
>16 гигов оперативы
>И эта срань умудряется на этом лагать.
>Спасибо, но я лучше и дальше на эклипсе и vs code поеду
Чел, у меня проц 10летний и на нем не лагает (3570k)
>Но ты сейчас врёшь и не краснеешь:
Ты типа читать не умеешь? Это дебаггер. Не равно запуск как бы.
Ну в любом случае не знать как работает та или иная конструкция в языке это наверное ОК, главное уметь быстро разобраться что к чему. Если эти варарги нигде не используются в проекте, то в памяти такие знания могут быстро забыться.
3 года на одном проекте = человек, который достиг своего потолка как по зарплате, так и по знаниям. Сразу вангую, что платят ему меньше 200к.
> Это какой-то массовый псиоп нищих дидов на линуксе? Ни разу за 3 года не испытал серьёзных багов, которые не решались бы простой переустановкой шинды. И то бывало крайне редко
Синтактический сахарок для отправки ArgumentType[] muhArgs методам. Учитывая, что так и так переменное количество переменных остаётся массивом, то вообще насрать. И если коллеги этого "мидла" не могут разобраться, что он имеет ввиду, посылая методу массивы, то мои соболезнования, они не лучше.
мимо безработный, штудирую книжку из шапки
> Какие у тебя задачи, что ты выбрал джаву?
Бабок заработать.
> Судя по коду на скрине
Это не мой код, а Хорстмана.
> 1) Сидишь на их игровой прошивке вместо ОС
Линакс на десктопе потешная вещь:
1. Постоянная ебля с wi-fi. Все дрова что там есть - кривые.
2. Ебля с вайландом/гномом/ксоргом. Вечные проблемы с хибернейтом.
3. Ебля с wine.
4. Из десятка поддерживаемых fs - нормальной нет. Рассыпаются все.
5. Дистрибутивов нормальных нет.
4. zfs.
5. арчик
>Бабок заработать.
Не заработаешь. Ты тупой и ленивый слишком.
> 4. zfs.
Мусор для которого надо 4 гб оперативы и сторонний nongpl модуль ядра. А в линаксе апи в ядре такое штабильное ммм.
> 5. арчик
Прыщи выведи сначала, а потом эту хуетенюшку советуй, лолец малой.
Бабки сейчас в голанге, это новая игрушка у энтерпрайзных бумажных архитекторов.
> Бабки сейчас в голанге
>сертифицирован 3 .net
>java 1.5 - 1.8
>микрософт машет хуем разрывает контракты на ms sql, закрывает azura, блочит комунити студию к загрузке.
>автокад блочит и перадки.
> голанг
В озоне если только. А другие врядли туда покатятся с такими то условиями.
Я лично жду когда венду заблочат удалённо на всех компах этой страны. Вот тогда можно будет бабок нарубить.
А какое отношение тут имеет автокад, микрософт и джава к голангу?
>>сертифицирован 3 .net
>>java 1.5 - 1.8
это к чему? что никто ничего нового пробовать не хочет?
Это просто мода разгоняемая бигтехами. Под их нужды этот язык нужен, поэтому надо чтоб на него переходили и все остальные, чтоб не выращивать кадры самим из пхпшников.
>которые ругают джаву за бойлерлейт
Ругают за лишние абстракции + многослойную тяжелую машинерию в виде спринга и хубирнейта.
>>3129719
ИМХО уровень в условном яндексе/вк/озоне/авито будет повыше чем например в тинькоффе или сбере. Не говоря уже про остальные банки.
Джава это нынче исключительно банки, финтех и энтерпрайз. Ну то есть бабки зарабатывать можно, но интересных инфра проектов, на которых можно хорошо качать технические скиллы, практически нет, это как раз на гоуленге делают нынче.
что и зачем качать? Качаешь скиллы, чтобы зарабатывать бабки, если успешно уже это делаешь, то зачем идти в гоуленг?
>что и зачем качать
Что качать?
- concurrency
- сетевой стек, сетевые протоколы
- общая инфра, кишочки докера, кубернетиса
- кишочки работы движков СУБД
Вот как минимум 4 направления для бекенд разраба.
>>3129797
>Качаешь скиллы, чтобы зарабатывать бабки, если успешно уже это делаешь, то зачем идти в гоуленг
Дело не в гоуленге, а в том, что нужно искать себе хороший проект, где можно будет вырасти в знаниях по части инфраструктуры, а не просто стать очередным экспертом в бизнес-процессах очередного предприятия (с таким успехом можно в 1С вкатываться, так как область применения очень похожая).
И так уж случилось, что более технические инфра задачи решают на гоуленге, а автоматизация бизнес процессов ,электронный документ, финтех, системы всякого учета - это скорее жаба.
Именно так, я этому переобуванию в прыжке каждый раз удивляюсь. Go буквально обрезанная джава 1.4, но это круто, потому что не джава, хотя на джаве можно писать так же как на Го. Или например когда это кто-нибудь гордился что в джаве нет какой-то стандартной фишки? А Гоферы только выигрывают что в Го нет эксепшенов, нет банальных дженериков! и гоферы ноют что нужно копипастить все по 50 раз, но Го все равно круто, джава отстой. Это пиздец как это все в голове умещается.
>Ругают за лишние абстракции + многослойную тяжелую машинерию в виде спринга и хубирнейта.
Так язык тут причем? Не надо - не используй
И там что GC - это прошлый век и слабая производительность. Но только не Го, потому что в Го тоже GC, но в Го GC - это удобство, скорость и безопасность.
>Ругают за лишние абстракции + многослойную тяжелую машинерию в виде спринга и хубирнейта.
Под Го уже написали свой спринг, всё жду когда окажется что это - другое
>написали свой спринг
source?
>>3129875
Ну а как не использовать, если оно чуть ли не в каждом проекте есть, куда не приди?
Сейчас я как раз работаю там, где этого всего говна нет - используем guice + jdbc, никаких хубирнейтов и спрингов, но в целом это исключение для индустрии (ну или для российских проектов во всяком случае).
Причем у говнянга гц выкручен в частые сборки, из за чего пропускная способность ниже, чем у жабы. Но зачем рассказывать об этом снг-гоям? До них только сейчас дошел хайп говнянга (хотя прямо сейчас на западе говнянг помирает), лет через пять узнают, что из наебывали, будут переписывать на раст/etc
>source?
https://github.com/uber-go/fx
https://github.com/google/wire
>Ну а как не использовать, если оно чуть ли не в каждом проекте сть, куда не приди?
Ну так это вопрос к программистам, а не к языку. Видишь, и на Го спринг пишут
Это мне тут недавно один затирал, что джава нравится консерваторам, что нет дефолтных значений для параметров и приходится кучу перегрузок писать, а джавистам и похуй, они не замечают. Когда я спросил а где в Го дефолтные значения, неужели Гоферам тоже похуй и они не замечают - он ушел в ступор.
>>джава нравится консерваторам, что нет дефолтных значений для параметров и приходится кучу перегрузок писать
У меня очень мало перегрузок поэтому и вправду не особо напрягает. Это просто решается через дата-обжекты вместо 5+ параметров. Да и большое количество дефолтов считается скорее говнодизайном.
Это не спринг, ну точнее это просто DI контейнеры с чего спринг и начинался когда-то в нулевые. Под спрингом понимают веб-фреймворк где у тебя все из коробки для перекладывания жсонов (Как asp.net core в c#, laravel в php, django в python). В го ничего такого нет, это не go way.
>Ругают за лишние абстракции + многослойную тяжелую машинерию в виде спринга и хубирнейта.
Можно подумать Гёц лично приходит и наворачивает абстрации и заставляет использовать Спринг. Я работал в проектах без Спринга и Хибера и не могу сказать, что есть какая-то разительная разница. Больше зависит от подхода к разработке, если писать хорошо то код на спринге будет и читаться хорошо и работать быстро.
> что нет дефолтных значений для параметров и приходится кучу перегрузок писать
C 9ки в java https://docs.oracle.com/javase%2F9%2Fdocs%2Fapi%2F%2F/java/util/Objects.html#requireNonNullElse-T-T-
Дебильное название.
requireNonNull - выбрасывает исключение
requireNonNullElse - уже нет.
Надо было назвать nonNullElse, nonNullOrDefault или defaultIfNull
Интересная мысль, не думал об этом. Но этом можно просто на любой джаве самому написать
>Это не спринг, ну точнее это просто DI контейнеры с чего спринг и начинался
Спринг Кор - это до сих пор DI и бин менеджмент
>В го ничего такого нет, это не go way.
Тоже самое говорили и про DI. Превращение в джаву неизбежно
но это конечно не избавит от кучи нулов в конце списка параметров в вызове
Тогда уж наверное идиоматичнее будет Optional.orElse делать, и короче и с 8ки доступно
Хотя пизжу, nonNull тоже не подходит. getOrDefault должно быть.
Доложите жизненность пикчи, коллегчики
Серьезно, кто-то переписывает всё с нуля, если за час не нашёл решения проблемы?
>кишочки работы движков СУБД
Как в этом начать разбираться? Есть книги какие-то и т.д?
Вроде хочешь начать разбираться, а потом такой, да запрос вроде шустро выглядит, 1+N нет, ай да и похуй
Щас бы импортить целый говнокласс ради одного обосааного метода, который можно написать обычным тернарником. Хррр тьфу.
>>Как они узнают
никак
>>какие подводные
заблочат ключ, придется гуглить другой или использовать прокси
Там нет и подсказок по html с js и ии нет, даже лсп нельзя другое подключить. В общем-то только чистая жаба.
Там кучи функционала нет. Например, нельзя томкат подвязать к зеленой кнопке.
Я использую, мне - норм. Попробуй.
>>3131612
Томкат нельзя, но спринг кстати вполне себе стартует.
>Под спрингом понимают веб-фреймворк где у тебя все из коробки для перекладывания жсонов
Кто?
>asp.net core в c#, laravel в php, django в python
Так то по логике продолжателем списка со стороны джавы должен быть JSP/JSF, если бы оное было живо. Спринг - это все таки другое.
>Это не спринг, ну точнее это просто DI контейнеры с чего спринг и начинался когда-то в нулевые
>В го ничего такого нет, это не go way.
Если уже появился DI, появление экосистемы похожей на JavaEE или спринг - лишь вопрос времени. Программисты необучаемы.
>даже лсп нельзя другое подключить
ох уж эти зумеры, вычившие буквы лсп)
поддержка языков в идее делается плагинами, то что нет возможности подключить лсп - не значит что другие языки не поддерживаются
Погугли хоть https://blog.jetbrains.com/platform/2023/07/lsp-for-plugin-developers/
К чему это? Функция доступна только в ультимейт, доступна.
Ты же придумал за меня тезис, который я не утверждал, сам развил, сам разоблачил и сам же поржал. Хорош. На уровень мидла идешь, а то и сеньки.
Так его и воспитывали индусы, он код писал в 2010 когда нахуячить абстрактные фабрики и Impl было чем то нормальным.
Он коды писал в последний раз где-то в начале нулевых годов.
Еще один гений. Я где-то утверждал обратное?
Я говорю про то, что я не могу подключить это например https://docs.oracle.com/en/graalvm/jdk/21/docs/tools/lsp/
То, что разработали оракл, а не жидбрейнс. Не могу сам навернуть любой яп, а довольствуюсь тем, что разрешили жидбрейнсы.
Сложный тезис, понимаю. Старость не радость все таки.
таксист
Я б начал все детали рассказывать вплоть до названий классов. Если ему интересно слушать описание в полчаса как эта поебень работает - мне не трудно.
Я ему так и сказал, типа "Мне рассказывать, как я создал репозиторий и сервис и т.д?", а он навёл аналогию про туалет и мытьё рук. Короче хз, чёт вроде он и прав, а чёт вроде и доебался по хуйни.
У меня в команде типы в понедельник не могли рассказать, чем в пятницу занимались.
>>Пишут Basic или Simple.
Название должно отражать чем каждая реализация отличается. Симпл хотя бы подразумевают что есть димпл хард.
Но идея же типа в том, чтобы писать "ны вырост". Сегодня одна, а через три месяца срочно потребовалось ещё две
>На самом деле бойлерплейт интерфейсы это чистейший бойлерплейт.
Писал не перечитывая, тут, очевидно, имелся в виду интерфейс у которого одна реализация.
>>писать "ны вырост"
Апфронт дизайн - это антипаттерн. Надо делать расширяемую архитектуру, а не городить классы на все случаи жизни. Все равно не угадаешь как оно пойдет.
>>Сегодня одна, а через три месяца срочно потребовалось ещё две
Когда понадобится, тогда и создавай. Интерфейс выделяется секунд за 10 в идее.
Вот ещё по этой теме докину, одно из моих самых последних открытий в программировании — всё не предусмотришь. Как конкретный тезис я это вывел спустя 3 года программирования. Раньше задачу этого выполняло "нет времени щас этим заниматься", что подразумевало, что было бы время и что это, якобы, возможно.
>Интерфейс выделяется секунд за 10 в идее.
8 сторипойнтов, полспринта минимум, тащ менеджер!
Такой дилеммы впринципе не должно возникать.
Если встает постановка вопроса - "надо ли писать интерфейс, если заведомо известно что имплементация - одна", вы уже проиграли, спринг вас ебет в жопу, а дизайн приложения - говно.
Расширяемость - это значит можно что то допилить без особых переделок. Например в бд пол сохранять в varchar, а не boolean. А апфронт - это нахуячить отдельную таблицу на 50 видов гендеров с возможностью добаления своего, когда в тз про них ни слова не было потом еще и извиняться придется.
>>3132582
Курс сторипоинта обвалился, теперь в спринт влезает вдвое больше.
Сейчас бы в 2к24 сидеть на одном проекте со джаваскуфидонами, которые кое-как осилили свой спринг бут и хубирнейт, а в проекте все обмазано публик клусс МайСервисИмпл имплементс Майсервис на 3к строк без тестов..
Изначально мертворожденный проект как и большинство проектов спринга
Пишут. Иначе ты нарушаешь СОЛИД, чел.. Читай дядюшку Боба. публик интерфейс МайСервис
публик клусс МайСервисИмпл имплементс МайСервис!
купил я, значит, курс на джавараше, и все пока устраивает, но
Хочу писать код не только внутри их модуля, а в отдельном "своем" приложении. Как сейчас с этим дела обстоят? Обязательно ли качать Линукс, и что вообще делать?
>"Мне рассказывать, как я создал репозиторий и сервис и т.д?"
Ты на джуна шел сюда по задачам которые ты решал, лол))
>Название должно отражать чем каждая реализация отличается
Чел... Контроллер - Сервис - Репозиторий. Все! Говорит тебе Кабан добавить юзеров в систему. Ты создаешь ЮзерКонтроллер. Затем ЮзерСервисИмл. Затем ЮзерРепозитори. Все!
Нормально обстоят. У меня 80% знакомых джавистов сидит на Винде (я бы удивлен). Качай Intelij IDEA Community edition
>понять контракт окружающего его модуля (пакета)
Чего? Это и на классах прекрасно работает. А любителей с нихуя насрать интерфейсами и лепить Impl мы гоним с проекта на хуй
>Контроллер - Сервис - Репозиторий
Брух
>Говорит тебе Кабан добавить юзеров в систему
Сходил в админку и навалил юзеров, лол.
Спасибо, чуть позже гляну
И ещё вопрос - обилие фигурных скобок в if-else. Все пытаюсь понять, но не особо выходит. Или пока забить, и с практикой придет? Я пока делаю без них, так как не было нужды
Вот что я имею ввиду
Scanner sc = new Scanner(System.in);
int i = 2;
System.out.print("Введите целое число: ");
if(sc.hasNextInt()) {
i = sc.nextInt();
System.out.println(i*2);
} else {
System.out.println("Вы ввели не целое число");
}
Здесь же спокойно можно без них обойтись
>Курс сторипоинта обвалился, теперь в спринт влезает вдвое больше.
Совсем дурак?
Благодаря внедренным изменениям, велосити команды удвоилось. Дайте премию гражданин начальник.
Вот как надо!
>>Затем ЮзерСервисИмл. Затем ЮзерРепозитори.
Просто создаешь ЮзерСервис без всякого импл и все.
Зависит от кодстайла команды, но почти всегда тебе скажут что они нужны во избежание неявного поведения и багов.
Нет конечно, и ты привел хороший пример почему нельзя. Если ты пишешь без фигурных скобок, то только следующее выражение считается принадлежащим к if блоку.
Во-первых без скобок с else это вообще не скомпилится, а если бы не было else, то без скобок выражение System.out.println(i*2); будет выполняться вне блока, то есть безусловно.
>
>Здесь же спокойно можно без них обойтись
А ты попробуй, даун. Будешь послан компилятором нахуй в конкретно твоем случае.
Нахуя на двач со своей тупорылостью приходишь?
Если одна строка после ифа или елса то можешь не ставить,в твоем примере в блоке елс будет выполнена только первая строка по условию а вторая будет воспринята компилятором как будто находится за блоком елс
Поглядите на потного сноба-синьора. Чувствует, что ему в жирную спину дышат упругие джависты
>Чувствует, что ему в жирную спину дышат упругие джависты
Ждем следующий тред о вкате от неосилятора.
>упругие джависты
Упругие жависты >>> скуфы
Надеюсь их все больше будет, а то уже неможно, одни душнилы старые неняшные.
Пиши как хочешь, не нужны скобки - не пиши.
Я вот вообще ебошу прям внутри условий всякое.
Я больше этих коллег знаю, лол.
Знаааешь, так грустно осознавать, что вокруг одни дебилы.
Эта отрыжка даже до ревью человеком не доберется. Банально сонар не пропустит.
Начнем с того, что он со своей выебистостью школьника даже работу найти не сможет.
Утютю. Сонар не допустит. Как же тебя трясет, лол.
>>3133098
Хз, я факты сказал. Сколько дней назад вопрос задал, хоть один человек ответил? Нет. >>3126939
Похоже до 17 главы спеки никто и не доходил, лол.
Может скажем ему?
Что именно уметь?
Круды писать? Это не сложно.
А так, у меня нет опыта написания всякой энтерпрайз хуйни, поэтому в этом плане особо не напираю.
Но честно, так не хочется, понимая что придется общаться со всякими тупыми дебилами душнилами, которые будут ебать по всему чему угодно, лишь бы самоутвердится.
У меня вопрос: что пишут настоящие кодеры? Потому что у меня стойкое ощущение, что я нихуя не умею практически проработав 3 года.
А ты никому и не нужон, по тебе сразу видно, что ты неприятный человек.
Что я неприятного сделал? Сказал факт, что я лучше знаю кор жабы, чем будущие коллеги? Или то, что в личном коде ты можешь придерживаться любого кодстайла, писать любую хуйню и никто тебя не в праве ограничивать? Ууу крамола, как можно)
>чем будущие коллеги
Так а с чего ты взял что тебя кто то на работу возьмёт?
Ну потому, что я ахуенный? И уже имею приглосы на стажерство
Я конечно не опытный, но по-моему вот так >>3133087 писать всё не стоит. Выглядит конечно круто и непонятно, но читается сложно.
Пиши как хочешь в своих проектах. Я эту хуйню писал, какому-то студику на форуме, с целью чтобы если он кому-то ее сдал, то тоочно не повирили, что автор это он. Считай медвежья услуга)
Я опытный, и проблема у этого чела не в говнокоде, а в его выебистости.
> проблема не в коде
То есть это нормально в продакшн коде писать пре-кременты и побитовые сравнения?
Я правильно понимаю, что на сложных больших проектах пишут вот такой сложный и непонятный код?
Так а какой код пишут настоящие синьоры хардкорные, кто из тетрадей и книжек по компьютерным наукам не вылазит? Какой сложности задачи? Я хочу понимать, в какую сторону развиваться.
Я даже не джун. Но вроде сеньки архитектуру в общем разрабатывают. Кружочки там с квадратиками рисуют, ну и зависимости проекта разрешают.
А так, можешь вместе со мной изучать многопоточку, знаешь какая она прикольная? Ухх просто.
Да, многопот очка внатури сложная и интереса. Ты по чему изучаешь?
>>3133353
Там какой-то кал в этих самых исходниках.
>Там какой-то кал в этих самых исходниках.
А можт у тебя в голове кал?
https://docs.oracle.com/javase/specs/jls/se21/html/jls-17.html
https://www.cs.umd.edu/~pugh/java/memoryModel/jsr133.pdf
https://research.ibm.com/haifa/Workshops/PADTAD2005/papers/jmm.pdf
https://gee.cs.oswego.edu/dl/html/j9mm.html
https://dl.acm.org/doi/epdf/10.1145/3360568
Ну и книгу гетца читал, само собой.
Еще вот эти хороши для вката
https://shipilev.net/blog/2014/jmm-pragmatics/
https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/
Вот это не кал что ли? Вот эти приведения какие-то нахуй. Выглядит как костыли.
>шипилеша
Бля...чел... Это, кстати, отличный пример, почему канкаренси в жвм и жабе сделано через такую задницу, что люди годами пишут книги, выдрачивают статьи и заучивают как стихи все хитровыебанные хуитки и прочее неочевидное поведение жмм.
Позабудешь какое-нибудь правило жмм и в лучшем случае, твой понос на жабе встанет колом
>айбернейт
>2к24
https://youtu.be/OV_yO9YVITE?t=629
Бля...чел...ты скуфидон, который решил затащить айбернейт в проект? Зачем?
эм, тебе не надо заучивать повеленре, т.е. следствие. тебе всего лишь надо понять модель в общем, чтобы ты сам мог говорить, когда и какое поведение будет.
Да и чем тебе шипилев не нравится? Правильные вещи говорит и опыт у него уникальный.
>Spring Data JPA
Это буквально Hibernate, хуеблядина ты тупорылая
А хибернейт типа на святом духе работает. Там под капотом тот же JDBC.
Именно, лалка ебучая. И эта хуйня в 90% проектов.
То, что руками больше не надо конфигурировать SessionFactory через persistence.xml не означает, что хуйбернет куда-то делся.
>>руками больше не надо конфигурировать SessionFactory
Ты откуда вылез? Из 2007 что ли?
А я наоборот думал, что абстрактные фабрики и имплы это полный хайп в 2024. А как грамотно писать тогда, чтобы в джава-треде уважали? Есть может статьи какие-то, или примеры конкретные с применением современных подходов, не 2010 года?
По делу высрешь что-нибудь? Хуйбернет сейчас ВЕЗДЕ. Жук - только в твоем залупарии
Я с того типа с data jpa рофлил просто, но и он скорее всего рофлил
Это очень императивный код, который только в путь использует побочные эффекты, мутабельность и прочее прочее.
И еще жаба менее выразительна в плане применения операторов. Были б у меня возможности с пика, я б такоооое написал, эх. А еще оптимизация хвостовой рекурсии, функции первых порядков, тайпклассы с параметризацией по контейнеру...
>Хуйбернет сейчас ВЕЗДЕ. Жук - только в твоем залупарии
Spotify использует жук.