125 Кб, 1024x1024Вики по джаве: https://github.com/java2ch/java-thread/wiki (доступна для редактирования всем)
Предыдущий: >>3404287 (OP)
Предыдущий: >>3404287 (OP)
>>4102
Если ты няшный студент, готовый так сказать к глубокой проработке фреймворков - то вперед. Иначе очень трудно и лучше ракать в го или 1с там
Если ты няшный студент, готовый так сказать к глубокой проработке фреймворков - то вперед. Иначе очень трудно и лучше ракать в го или 1с там
>>4117
Да! Так и есть. Ух, вот бы каждое утро просыпаться, а тебя хвалят и хвалят.
Лучший язык на планете~~
>Какие же вы все - молодцы!
Да! Так и есть. Ух, вот бы каждое утро просыпаться, а тебя хвалят и хвалят.
>Как же джава хороша.
Лучший язык на планете~~
>>4087 (OP)
Как изучить джаву без привязки к спрингу, если у меня уже есть опыт с другими ЯП? Чтобы мне не начинали в очередной раз пытаться рассказывать, что такое переменные, циклы, классы и прочее.
Как изучить джаву без привязки к спрингу, если у меня уже есть опыт с другими ЯП? Чтобы мне не начинали в очередной раз пытаться рассказывать, что такое переменные, циклы, классы и прочее.
>>4128
А что за курсы?
А что за курсы?
>>4087 (OP)
Как выживать на проектах, которые писали лоускильные ноунеймы из провинции? В очередной раз попал в болото из Контроллер - МайСервисИмпл имплементс МайСервис - Рипазитари. Вся логика, разумеется, в сервисе. Сервис - файл на 3.5-5к строк. Тесты? Какие тесты? Сервис и бизнес-логика завязаны на другие сервисы, а они на другие сервисы, а они на друг... Юнит-тестов нет, интеграционных тестов нет. Обещают переписать на микросервисы и тогда все заверт.. но воз и ныне там. Релиз раз в полгода, ручной регрес и жалкие попытки энд ту энд со стороны куашников. Ливать?
Как выживать на проектах, которые писали лоускильные ноунеймы из провинции? В очередной раз попал в болото из Контроллер - МайСервисИмпл имплементс МайСервис - Рипазитари. Вся логика, разумеется, в сервисе. Сервис - файл на 3.5-5к строк. Тесты? Какие тесты? Сервис и бизнес-логика завязаны на другие сервисы, а они на другие сервисы, а они на друг... Юнит-тестов нет, интеграционных тестов нет. Обещают переписать на микросервисы и тогда все заверт.. но воз и ныне там. Релиз раз в полгода, ручной регрес и жалкие попытки энд ту энд со стороны куашников. Ливать?
>>4143
А что не так?
А что не так?
>>4143
А что тебя на таком проекте убивает - пойми это для начала?
Так то у тебя один из двух стульев:
Либо мимикрируй под остальных долбоебов и не отсвечивай, Приходи-уходи на работу по графику. Не овертаймь, не рви жопу, ни с кем не спорь, в залупу не лезь. Лутай тихонечко свой оклад, параллельно качайся, ищи альтерннативы, и годика через 2 сваливай.
Либо наоборот максимально лезь в залупу, но по умному. Общайся с стейкхолдерами, понимай что их устраивает не устраивает, предлагай инициативы, выбивай себе большие свободы и полномочия, подминай под себя лоускиллов и учи их хорошим практикам. Это путь high risk high reward - ибо инициатива ебет инициатора. Если ты сам лоускилльный, особенно это касается софт скиллов, тебя просто затраллят и либо ты сам выгоришь и сопьешься, либо тебя начальство отстрелит как токсика.
>Как выживать
А что тебя на таком проекте убивает - пойми это для начала?
Так то у тебя один из двух стульев:
Либо мимикрируй под остальных долбоебов и не отсвечивай, Приходи-уходи на работу по графику. Не овертаймь, не рви жопу, ни с кем не спорь, в залупу не лезь. Лутай тихонечко свой оклад, параллельно качайся, ищи альтерннативы, и годика через 2 сваливай.
Либо наоборот максимально лезь в залупу, но по умному. Общайся с стейкхолдерами, понимай что их устраивает не устраивает, предлагай инициативы, выбивай себе большие свободы и полномочия, подминай под себя лоускиллов и учи их хорошим практикам. Это путь high risk high reward - ибо инициатива ебет инициатора. Если ты сам лоускилльный, особенно это касается софт скиллов, тебя просто затраллят и либо ты сам выгоришь и сопьешься, либо тебя начальство отстрелит как токсика.
>>4175
Сейчас только синтаксис и кишки JVM. Для синтаксиса, как я понимаю, можно первый том Хорстманна проштудировать и первую половину второго?
Сейчас только синтаксис и кишки JVM. Для синтаксиса, как я понимаю, можно первый том Хорстманна проштудировать и первую половину второго?
>>4187
Для именно синтаксиса ты можешь буквально что угодно открыть, начиная туториала оракла, хорстмана, шилдта, заканчивая вовсе жаварашем каким-нибудь. Вообще не приципиально как по мне, он учится в первую неделю, если ты уже имеешь опыт других яп.
По кишкам есть, например, конференции jpoint и вот у шипилева классные выходили https://youtube.com/playlist?list=PLecCTjz_4ylyyvYExhPAzB4Mqn3Q_kEj6
Можешь начать с этого, как по мне, если ты хоть что-то начнешь смотреть/читать, то источники по этой или смежной теме ты так или иначе найдешь через ссылки в этих же источниках. Просто типичная история, а вот подробнее об этом читайте туть, это не тема книги/конференции и тд.
>Для синтаксиса, как я понимаю
Для именно синтаксиса ты можешь буквально что угодно открыть, начиная туториала оракла, хорстмана, шилдта, заканчивая вовсе жаварашем каким-нибудь. Вообще не приципиально как по мне, он учится в первую неделю, если ты уже имеешь опыт других яп.
По кишкам есть, например, конференции jpoint и вот у шипилева классные выходили https://youtube.com/playlist?list=PLecCTjz_4ylyyvYExhPAzB4Mqn3Q_kEj6
Можешь начать с этого, как по мне, если ты хоть что-то начнешь смотреть/читать, то источники по этой или смежной теме ты так или иначе найдешь через ссылки в этих же источниках. Просто типичная история, а вот подробнее об этом читайте туть, это не тема книги/конференции и тд.
59 Кб, 797x438>>4143
Давай конкретный пример. В целом в этом нет ничего плохого.
Всё верно. А где ей ещё быть? Не в контроллере же. Не в репозитории же.
Многовато, но открой серьёзный проект, там одни интерфейсы по 1000 строк, правда 90% это документация. Если нет дублирования кода в классе на 5,000 строк нет ничего плохого.
Это и называется слой бизнес логики. Можно взять целиком все эти сервисы и перенести в другой проект в виде библиотеки и вся бизнес логика будет работать без проблем.
А у тебя где находится бизнес логика?
> В очередной раз попал в болото из Контроллер - МайСервисИмпл имплементс МайСервис - Рипазитари.
Давай конкретный пример. В целом в этом нет ничего плохого.
> Вся логика, разумеется, в сервисе.
Всё верно. А где ей ещё быть? Не в контроллере же. Не в репозитории же.
> Сервис - файл на 3.5-5к строк.
Многовато, но открой серьёзный проект, там одни интерфейсы по 1000 строк, правда 90% это документация. Если нет дублирования кода в классе на 5,000 строк нет ничего плохого.
> Сервис и бизнес-логика завязаны на другие сервисы, а они на другие сервисы, а они на друг...
Это и называется слой бизнес логики. Можно взять целиком все эти сервисы и перенести в другой проект в виде библиотеки и вся бизнес логика будет работать без проблем.
А у тебя где находится бизнес логика?
>>4190
Спасибо!
Спасибо!
>>4191
Есть нечто смешное в том, что в ответ на высокую связность ты слету ответил что это нормально, мол именно так и проектируется бизнес логика, а вот момент с отсутствием юнит тестов у анона вообще никак не прокомментировал.
>Это и называется слой бизнес логики.
Есть нечто смешное в том, что в ответ на высокую связность ты слету ответил что это нормально, мол именно так и проектируется бизнес логика, а вот момент с отсутствием юнит тестов у анона вообще никак не прокомментировал.
241 Кб, 978x653>>4242
Потому что отсутствие тестов это плохо, что тут ещё комментировать. Пишут серьёзную большую программу и даже просто сами для себя не хотят проверить всё ли в ней работает как надо.
Заказчикам видимо тоже пофигу на это. Если у них чё-то не работает они просто поднимают трубку, звонят и им всё чинят.
Может там руководство и вообще работа в целом построена так, что они не считают нужным тратить время на тесты, ведь это удлиннить сроки в полтора-два раза а значит всё это время придётся оплачивать труд кнопкодавов, а бюджет и так мизерный, да с него ещё и откатить надо половину.
А может там вообще уже давно ничего нового и не делают, просто работает прога и нужен чел который будет туда иногда новые функции добавлять пару раз в год.
В общем я бы избегал такой работы если хочется развиваться как специалист.
Ни какого CI/CD и прочих современных практик, ставших уже нормой во всём мире, там видимо тоже нет.
А значит опыт который там анон получает не является коммерческим опытом разработки. А значит в другой серьёзной компании этот опыт учитываться не будет.
Потому что отсутствие тестов это плохо, что тут ещё комментировать. Пишут серьёзную большую программу и даже просто сами для себя не хотят проверить всё ли в ней работает как надо.
Заказчикам видимо тоже пофигу на это. Если у них чё-то не работает они просто поднимают трубку, звонят и им всё чинят.
Может там руководство и вообще работа в целом построена так, что они не считают нужным тратить время на тесты, ведь это удлиннить сроки в полтора-два раза а значит всё это время придётся оплачивать труд кнопкодавов, а бюджет и так мизерный, да с него ещё и откатить надо половину.
А может там вообще уже давно ничего нового и не делают, просто работает прога и нужен чел который будет туда иногда новые функции добавлять пару раз в год.
В общем я бы избегал такой работы если хочется развиваться как специалист.
Ни какого CI/CD и прочих современных практик, ставших уже нормой во всём мире, там видимо тоже нет.
А значит опыт который там анон получает не является коммерческим опытом разработки. А значит в другой серьёзной компании этот опыт учитываться не будет.
>>4087 (OP)
Чем плох ЮВАО? Погулял по картам по Перово и Измайлово - лампово. Чистенько, пешеходная инфраструктура есть, все эти пандусы, тротуары, ровные дороги, чистые улицы. Дома в основном невысокие - мало панелек, рядом лесопарк.
Открыл престижные Раменки и Крылатское - ну такое. Куча хрущей, которые давят сверху и как-то неуютно..
Чем плох ЮВАО? Погулял по картам по Перово и Измайлово - лампово. Чистенько, пешеходная инфраструктура есть, все эти пандусы, тротуары, ровные дороги, чистые улицы. Дома в основном невысокие - мало панелек, рядом лесопарк.
Открыл престижные Раменки и Крылатское - ну такое. Куча хрущей, которые давят сверху и как-то неуютно..
>>4191
Ну, т.е. ты не в курсе про SRP, low coupling, high cohesion? То, что у тебя один такой сервис на 5к строк зависит от 3-5 еще таких же сервисов на 5к строк каждый, а те тоже зависят от сервисов..
Ну, т.е. ты не в курсе про SRP, low coupling, high cohesion? То, что у тебя один такой сервис на 5к строк зависит от 3-5 еще таких же сервисов на 5к строк каждый, а те тоже зависят от сервисов..
>>4319
Ох уж эти "юнит тесты" где мокают все прямые зависимости и начинают "тестировать". А потом бегают и плачутся, что тесты у них хрупкие и их нужно переписывать на каждый чих
>замокать реализацию
Ох уж эти "юнит тесты" где мокают все прямые зависимости и начинают "тестировать". А потом бегают и плачутся, что тесты у них хрупкие и их нужно переписывать на каждый чих
>>4143
Ты на работу идёшь за деньгами. Пока твоё личное уважение к себе не ставят под сомнение я не вижу смысла воротить нос хоть от чего-либо. Говнокод это проблема кабанья, ты что с чистым, что с говном тратишь 8 часов в день.
Ты на работу идёшь за деньгами. Пока твоё личное уважение к себе не ставят под сомнение я не вижу смысла воротить нос хоть от чего-либо. Говнокод это проблема кабанья, ты что с чистым, что с говном тратишь 8 часов в день.
>>4330
Проблема мокирования, которую затронул автор саркастичного сообщения, связана с чрезмерным использованием моков в юнит-тестах, что приводит к хрупким и бесполезным тестам. Вот основные аспекты этой проблемы:
### 1. Тесты становятся хрупкими (fragile)
- Если замоканы все зависимости, то любое изменение в логике кода (даже корректное) ломает тесты, потому что моки жёстко завязаны на текущую реализацию.
- Пример: поменяли порядок вызовов методов или добавили новый – тесты падают, хотя бизнес-логика работает правильно.
### 2. Тесты не ловят реальные баги
- Моки подменяют реальное поведение зависимостей, поэтому тесты проверяют не "как код работает", а "как он представлен в голове тестирующего".
- Пример:
- Замокали базу данных → тест проходит, но в реальности SQL-запрос синтаксически неверен.
- Замокали внешний API → код работает с моком, но падает при реальном запросе из-за неучтённых полей в JSON.
### 3. Тесты превращаются в "ритуал"
- Вместо проверки логики тесты начинают просто верифицировать, что вызывались конкретные моки.
- Пример:
```python
# Плохо: тест не проверяет логику, только факт вызова мока
mock_db.insert.assert_called_once_with(data) # А если метод поменяет название?
```
Такой тест не упадёт, даже если код полностью сломан, но не вызвал именно этот метод.
### 4. Избыточная изоляция
- Юнит-тесты должны проверять логику модуля, но не обязательно изолировать все-все зависимости.
- Часто лучше использовать real-объекты (например, настоящие классы-сервисы без I/O) или стабы (заглушки с предсказуемым поведением), а не моки.
### Когда моки действительно нужны?
- Внешние сервисы (API, базы данных, файловая система).
- Опасные операции (например, удаление данных).
- Сложные зависимости, которые трудно настроить в тестах (например, аутентификация).
### Что делать вместо моков?
1. Писать интеграционные тесты – для проверки взаимодействия между модулями.
2. Использовать фейки (fake) – упрощённые, но рабочие реализации (например, in-memory база вместо PostgreSQL).
3. Тестировать поведение, а не реализацию – проверять результат, а не "как именно он был получен".
Проблема мокирования, которую затронул автор саркастичного сообщения, связана с чрезмерным использованием моков в юнит-тестах, что приводит к хрупким и бесполезным тестам. Вот основные аспекты этой проблемы:
### 1. Тесты становятся хрупкими (fragile)
- Если замоканы все зависимости, то любое изменение в логике кода (даже корректное) ломает тесты, потому что моки жёстко завязаны на текущую реализацию.
- Пример: поменяли порядок вызовов методов или добавили новый – тесты падают, хотя бизнес-логика работает правильно.
### 2. Тесты не ловят реальные баги
- Моки подменяют реальное поведение зависимостей, поэтому тесты проверяют не "как код работает", а "как он представлен в голове тестирующего".
- Пример:
- Замокали базу данных → тест проходит, но в реальности SQL-запрос синтаксически неверен.
- Замокали внешний API → код работает с моком, но падает при реальном запросе из-за неучтённых полей в JSON.
### 3. Тесты превращаются в "ритуал"
- Вместо проверки логики тесты начинают просто верифицировать, что вызывались конкретные моки.
- Пример:
```python
# Плохо: тест не проверяет логику, только факт вызова мока
mock_db.insert.assert_called_once_with(data) # А если метод поменяет название?
```
Такой тест не упадёт, даже если код полностью сломан, но не вызвал именно этот метод.
### 4. Избыточная изоляция
- Юнит-тесты должны проверять логику модуля, но не обязательно изолировать все-все зависимости.
- Часто лучше использовать real-объекты (например, настоящие классы-сервисы без I/O) или стабы (заглушки с предсказуемым поведением), а не моки.
### Когда моки действительно нужны?
- Внешние сервисы (API, базы данных, файловая система).
- Опасные операции (например, удаление данных).
- Сложные зависимости, которые трудно настроить в тестах (например, аутентификация).
### Что делать вместо моков?
1. Писать интеграционные тесты – для проверки взаимодействия между модулями.
2. Использовать фейки (fake) – упрощённые, но рабочие реализации (например, in-memory база вместо PostgreSQL).
3. Тестировать поведение, а не реализацию – проверять результат, а не "как именно он был получен".
>>4330
Проблема мокирования, которую затронул автор саркастичного сообщения, связана с чрезмерным использованием моков в юнит-тестах, что приводит к хрупким и бесполезным тестам. Вот основные аспекты этой проблемы:
### 1. Тесты становятся хрупкими (fragile)
- Если замоканы все зависимости, то любое изменение в логике кода (даже корректное) ломает тесты, потому что моки жёстко завязаны на текущую реализацию.
- Пример: поменяли порядок вызовов методов или добавили новый – тесты падают, хотя бизнес-логика работает правильно.
### 2. Тесты не ловят реальные баги
- Моки подменяют реальное поведение зависимостей, поэтому тесты проверяют не "как код работает", а "как он представлен в голове тестирующего".
- Пример:
- Замокали базу данных → тест проходит, но в реальности SQL-запрос синтаксически неверен.
- Замокали внешний API → код работает с моком, но падает при реальном запросе из-за неучтённых полей в JSON.
### 3. Тесты превращаются в "ритуал"
- Вместо проверки логики тесты начинают просто верифицировать, что вызывались конкретные моки.
- Пример:
```python
# Плохо: тест не проверяет логику, только факт вызова мока
mock_db.insert.assert_called_once_with(data) # А если метод поменяет название?
```
Такой тест не упадёт, даже если код полностью сломан, но не вызвал именно этот метод.
### 4. Избыточная изоляция
- Юнит-тесты должны проверять логику модуля, но не обязательно изолировать все-все зависимости.
- Часто лучше использовать real-объекты (например, настоящие классы-сервисы без I/O) или стабы (заглушки с предсказуемым поведением), а не моки.
### Когда моки действительно нужны?
- Внешние сервисы (API, базы данных, файловая система).
- Опасные операции (например, удаление данных).
- Сложные зависимости, которые трудно настроить в тестах (например, аутентификация).
### Что делать вместо моков?
1. Писать интеграционные тесты – для проверки взаимодействия между модулями.
2. Использовать фейки (fake) – упрощённые, но рабочие реализации (например, in-memory база вместо PostgreSQL).
3. Тестировать поведение, а не реализацию – проверять результат, а не "как именно он был получен".
Проблема мокирования, которую затронул автор саркастичного сообщения, связана с чрезмерным использованием моков в юнит-тестах, что приводит к хрупким и бесполезным тестам. Вот основные аспекты этой проблемы:
### 1. Тесты становятся хрупкими (fragile)
- Если замоканы все зависимости, то любое изменение в логике кода (даже корректное) ломает тесты, потому что моки жёстко завязаны на текущую реализацию.
- Пример: поменяли порядок вызовов методов или добавили новый – тесты падают, хотя бизнес-логика работает правильно.
### 2. Тесты не ловят реальные баги
- Моки подменяют реальное поведение зависимостей, поэтому тесты проверяют не "как код работает", а "как он представлен в голове тестирующего".
- Пример:
- Замокали базу данных → тест проходит, но в реальности SQL-запрос синтаксически неверен.
- Замокали внешний API → код работает с моком, но падает при реальном запросе из-за неучтённых полей в JSON.
### 3. Тесты превращаются в "ритуал"
- Вместо проверки логики тесты начинают просто верифицировать, что вызывались конкретные моки.
- Пример:
```python
# Плохо: тест не проверяет логику, только факт вызова мока
mock_db.insert.assert_called_once_with(data) # А если метод поменяет название?
```
Такой тест не упадёт, даже если код полностью сломан, но не вызвал именно этот метод.
### 4. Избыточная изоляция
- Юнит-тесты должны проверять логику модуля, но не обязательно изолировать все-все зависимости.
- Часто лучше использовать real-объекты (например, настоящие классы-сервисы без I/O) или стабы (заглушки с предсказуемым поведением), а не моки.
### Когда моки действительно нужны?
- Внешние сервисы (API, базы данных, файловая система).
- Опасные операции (например, удаление данных).
- Сложные зависимости, которые трудно настроить в тестах (например, аутентификация).
### Что делать вместо моков?
1. Писать интеграционные тесты – для проверки взаимодействия между модулями.
2. Использовать фейки (fake) – упрощённые, но рабочие реализации (например, in-memory база вместо PostgreSQL).
3. Тестировать поведение, а не реализацию – проверять результат, а не "как именно он был получен".
>>4257
Правильно, хули, никто не спорит что отсутствие тестов это плохо. Другое дело что обычно в таких вот проектах с ебейшим транзитивным каплингом юнит тестов как раз и нету никогда, и нет их как раз из-за ебейшей связанности спроинговых компонент, из-за которой у анона просто не остается ручек, чтобы изолировать компонент под тесты. Но у культа такая связность - это норма, как ты отметил.
Но ты очень забавно ушел от темы, повеселил. Буквально свалил вину на всех - и начальство то виновато, и заказчик, и легасятина... Целое полотнище выводов вон настругал. Что называется, за деревьями леса не видать.
Я просто поражаюсь иной раз тому, как спрингокульт любит пиздеть о важности юнит тестирования, но при этом никогда не писать юнит тесты.
Правильно, хули, никто не спорит что отсутствие тестов это плохо. Другое дело что обычно в таких вот проектах с ебейшим транзитивным каплингом юнит тестов как раз и нету никогда, и нет их как раз из-за ебейшей связанности спроинговых компонент, из-за которой у анона просто не остается ручек, чтобы изолировать компонент под тесты. Но у культа такая связность - это норма, как ты отметил.
Но ты очень забавно ушел от темы, повеселил. Буквально свалил вину на всех - и начальство то виновато, и заказчик, и легасятина... Целое полотнище выводов вон настругал. Что называется, за деревьями леса не видать.
Я просто поражаюсь иной раз тому, как спрингокульт любит пиздеть о важности юнит тестирования, но при этом никогда не писать юнит тесты.
>>4330
Вот этот - хотя бы честный.
Вот этот - хотя бы честный.
>>4270
Забей. Солид в устах спрингофагов - инструмент демагогии, не больше. Чекни борисовский "спринг-построитель" на 15й минуте, его пук-среньк позорный по SOLIDу. А это - один из их главных гуру. Если спрингоблять раскрыла рот и начала перечислять при тебе принципы SOLID в контексте их фреймворка, она почти гарантированно не выкупает, какой шизоидный религиозный бред она несет.
Забей. Солид в устах спрингофагов - инструмент демагогии, не больше. Чекни борисовский "спринг-построитель" на 15й минуте, его пук-среньк позорный по SOLIDу. А это - один из их главных гуру. Если спрингоблять раскрыла рот и начала перечислять при тебе принципы SOLID в контексте их фреймворка, она почти гарантированно не выкупает, какой шизоидный религиозный бред она несет.
>>4386
А разве так не со всеми этими принципами, которые произносят как мантру? SOLID, KISS, PIDOR вот если следовать умным советам из книг написанных кучу лет назад, то ну тооочно все станет лучше. Там ведь хуйни не напишут
>какой шизоидный религиозный бред она несет
А разве так не со всеми этими принципами, которые произносят как мантру? SOLID, KISS, PIDOR вот если следовать умным советам из книг написанных кучу лет назад, то ну тооочно все станет лучше. Там ведь хуйни не напишут
63 Кб, mp4,320x320, 0:02
>>4372
Ну а как не плодить эти сервисы и не каплить? Вот я вчера решал задачу. Есть 30 установок программы в 30 разных организациях. Заказчик не может заставить их обновляться, хотят обновляются, не хотят не обновляются, их право. Соответственно есть 30 постгрес баз приложения и разброс версий этой базы 11 разных версий. Уплочено за поддержку всего этого и плотится ежегодно. А мне нужно сделать небольшую прогу, которая может подключиться к любой базе и делать кое-какие действия в ней. То есть мне нужно реализовать поддержку на данный момент 11 разных версий базы, в каждой версии какие-то таблицы есть, каких-то нет, какие-то поля в таблицах есть, каких-то нет.
Сделал СЕРВИС, который по версии базы из конфига возвращает имя роута, который ведёт к контроллеру, который отвечает за работу с той или иной версией базы.
Ну а как это ещё решить? Ну не делай сервис сделай switch чё легче станет что ли. А так хотя бы этот свич лежит отдельно в отдельном классе.
Прилетает запрос в котором в такую-то организацию нужно добавить такое-то значение. И не ебёт клиент какая там версия базы. И сегодня в этой организации одна версия базы, а завтра их переклинит они обновятся и будет более свежая.
Да и будет теперь кругом лезть этот СЕРВИС и всё будут от него коуплится.
А потом ещё один и ещё.
Ну а как не плодить эти сервисы и не каплить? Вот я вчера решал задачу. Есть 30 установок программы в 30 разных организациях. Заказчик не может заставить их обновляться, хотят обновляются, не хотят не обновляются, их право. Соответственно есть 30 постгрес баз приложения и разброс версий этой базы 11 разных версий. Уплочено за поддержку всего этого и плотится ежегодно. А мне нужно сделать небольшую прогу, которая может подключиться к любой базе и делать кое-какие действия в ней. То есть мне нужно реализовать поддержку на данный момент 11 разных версий базы, в каждой версии какие-то таблицы есть, каких-то нет, какие-то поля в таблицах есть, каких-то нет.
Сделал СЕРВИС, который по версии базы из конфига возвращает имя роута, который ведёт к контроллеру, который отвечает за работу с той или иной версией базы.
Ну а как это ещё решить? Ну не делай сервис сделай switch чё легче станет что ли. А так хотя бы этот свич лежит отдельно в отдельном классе.
Прилетает запрос в котором в такую-то организацию нужно добавить такое-то значение. И не ебёт клиент какая там версия базы. И сегодня в этой организации одна версия базы, а завтра их переклинит они обновятся и будет более свежая.
Да и будет теперь кругом лезть этот СЕРВИС и всё будут от него коуплится.
А потом ещё один и ещё.
>>4406
Ну ок, ты хотя бы не культист и в отрицалово не уходишь, есть надежда на конструктивный диалог.
А никак. В терминах спринговых реалий это тупо не решаемо. По совести, каждое из этих вот "кое каких действий", какие ты выполняешь в своей проге, хорошо было бы держать в таком виде, в каком их можно было бы черрипикать и переиспользовать независимо друг от друга. Не инжектить сервис из 5 тысяч строк, а затащить себе в клиентский компонент только ту часть, которая тебе нужна. Тогда количество зависимостей каждой из таких вот мини-компонент можно было бы свести к минимуму, и такой компонент можно было бы переиспользовать максимально гибко, не тащя за собой лапшу из остальных компонент. В терминах distance from main sequence меньше входящих транзитивных зависимостей == меньшая ригидность компонента == большая переиспользуемость и меньше риск того, что какие то из этих зависимостей изменятся и приведут к регрессиям в клиенте. В конечном итоге получилось бы нечто схожее с функциональной композицией, но на классах.
Но в спринге же так не принято - мы же в таком случае будем "плодить компоненты", айяйяй! Запутаемся, бедненькие, потеряемся! Мы попросту не можем не обьединять методы, которые хотим переиспользовать, по каким то абсурдным критериям типа "коли этот метод про пользователя, значит он должен быть частью UserService". А наобъединявшись, не можем потом переиспользовать то что наобьединяли. Вдовесок мы все это еще обвешаем аннотациями, чтобы компоненты приколотились друг к другу по декларациям инжекций и заодно вся бизнеслогика вендорлокнулась на фреймворк (слава богу эта мода потихоньку уходит в прошлое уступая место бутовым автоконфигурациям).
Я так то не оторванный от реалий идеалист, все могу понять. Просто в ебаном культе меня всю дорогу бесила вот именно эта пиздабольско-демагоговая манера. Нихуя такой дизайн не норма, и SOLIDом там даже близко не пахло. Это просто сложившаяся исторически говенная данность, где мы все варимся. Вот ты хотя бы признал что "да, хуево, но хуй знат как иначе", это я по человечески могу понять. А большинство долбоебов щас будет на говно исходить пытаясь доказать мне что это я просто не преисполнился и должен спринг выучить.
Ну ок, ты хотя бы не культист и в отрицалово не уходишь, есть надежда на конструктивный диалог.
>Ну а как это ещё решить?
А никак. В терминах спринговых реалий это тупо не решаемо. По совести, каждое из этих вот "кое каких действий", какие ты выполняешь в своей проге, хорошо было бы держать в таком виде, в каком их можно было бы черрипикать и переиспользовать независимо друг от друга. Не инжектить сервис из 5 тысяч строк, а затащить себе в клиентский компонент только ту часть, которая тебе нужна. Тогда количество зависимостей каждой из таких вот мини-компонент можно было бы свести к минимуму, и такой компонент можно было бы переиспользовать максимально гибко, не тащя за собой лапшу из остальных компонент. В терминах distance from main sequence меньше входящих транзитивных зависимостей == меньшая ригидность компонента == большая переиспользуемость и меньше риск того, что какие то из этих зависимостей изменятся и приведут к регрессиям в клиенте. В конечном итоге получилось бы нечто схожее с функциональной композицией, но на классах.
Но в спринге же так не принято - мы же в таком случае будем "плодить компоненты", айяйяй! Запутаемся, бедненькие, потеряемся! Мы попросту не можем не обьединять методы, которые хотим переиспользовать, по каким то абсурдным критериям типа "коли этот метод про пользователя, значит он должен быть частью UserService". А наобъединявшись, не можем потом переиспользовать то что наобьединяли. Вдовесок мы все это еще обвешаем аннотациями, чтобы компоненты приколотились друг к другу по декларациям инжекций и заодно вся бизнеслогика вендорлокнулась на фреймворк (слава богу эта мода потихоньку уходит в прошлое уступая место бутовым автоконфигурациям).
Я так то не оторванный от реалий идеалист, все могу понять. Просто в ебаном культе меня всю дорогу бесила вот именно эта пиздабольско-демагоговая манера. Нихуя такой дизайн не норма, и SOLIDом там даже близко не пахло. Это просто сложившаяся исторически говенная данность, где мы все варимся. Вот ты хотя бы признал что "да, хуево, но хуй знат как иначе", это я по человечески могу понять. А большинство долбоебов щас будет на говно исходить пытаясь доказать мне что это я просто не преисполнился и должен спринг выучить.
>>4406
Ну ок, ты хотя бы не культист и в отрицалово не уходишь, есть надежда на конструктивный диалог.
А никак. В терминах спринговых реалий это тупо не решаемо. По совести, каждое из этих вот "кое каких действий", какие ты выполняешь в своей проге, хорошо было бы держать в таком виде, в каком их можно было бы черрипикать и переиспользовать независимо друг от друга. Не инжектить сервис из 5 тысяч строк, а затащить себе в клиентский компонент только ту часть, которая тебе нужна. Тогда количество зависимостей каждой из таких вот мини-компонент можно было бы свести к минимуму, и такой компонент можно было бы переиспользовать максимально гибко, не тащя за собой лапшу из остальных компонент. В терминах distance from main sequence меньше входящих транзитивных зависимостей == меньшая ригидность компонента == большая переиспользуемость и меньше риск того, что какие то из этих зависимостей изменятся и приведут к регрессиям в клиенте. В конечном итоге получилось бы нечто схожее с функциональной композицией, но на классах.
Но в спринге же так не принято - мы же в таком случае будем "плодить компоненты", айяйяй! Запутаемся, бедненькие, потеряемся! Мы попросту не можем не обьединять методы, которые хотим переиспользовать, по каким то абсурдным критериям типа "коли этот метод про пользователя, значит он должен быть частью UserService". А наобъединявшись, не можем потом переиспользовать то что наобьединяли. Вдовесок мы все это еще обвешаем аннотациями, чтобы компоненты приколотились друг к другу по декларациям инжекций и заодно вся бизнеслогика вендорлокнулась на фреймворк (слава богу эта мода потихоньку уходит в прошлое уступая место бутовым автоконфигурациям).
Я так то не оторванный от реалий идеалист, все могу понять. Просто в ебаном культе меня всю дорогу бесила вот именно эта пиздабольско-демагоговая манера. Нихуя такой дизайн не норма, и SOLIDом там даже близко не пахло. Это просто сложившаяся исторически говенная данность, где мы все варимся. Вот ты хотя бы признал что "да, хуево, но хуй знат как иначе", это я по человечески могу понять. А большинство долбоебов щас будет на говно исходить пытаясь доказать мне что это я просто не преисполнился и должен спринг выучить.
Ну ок, ты хотя бы не культист и в отрицалово не уходишь, есть надежда на конструктивный диалог.
>Ну а как это ещё решить?
А никак. В терминах спринговых реалий это тупо не решаемо. По совести, каждое из этих вот "кое каких действий", какие ты выполняешь в своей проге, хорошо было бы держать в таком виде, в каком их можно было бы черрипикать и переиспользовать независимо друг от друга. Не инжектить сервис из 5 тысяч строк, а затащить себе в клиентский компонент только ту часть, которая тебе нужна. Тогда количество зависимостей каждой из таких вот мини-компонент можно было бы свести к минимуму, и такой компонент можно было бы переиспользовать максимально гибко, не тащя за собой лапшу из остальных компонент. В терминах distance from main sequence меньше входящих транзитивных зависимостей == меньшая ригидность компонента == большая переиспользуемость и меньше риск того, что какие то из этих зависимостей изменятся и приведут к регрессиям в клиенте. В конечном итоге получилось бы нечто схожее с функциональной композицией, но на классах.
Но в спринге же так не принято - мы же в таком случае будем "плодить компоненты", айяйяй! Запутаемся, бедненькие, потеряемся! Мы попросту не можем не обьединять методы, которые хотим переиспользовать, по каким то абсурдным критериям типа "коли этот метод про пользователя, значит он должен быть частью UserService". А наобъединявшись, не можем потом переиспользовать то что наобьединяли. Вдовесок мы все это еще обвешаем аннотациями, чтобы компоненты приколотились друг к другу по декларациям инжекций и заодно вся бизнеслогика вендорлокнулась на фреймворк (слава богу эта мода потихоньку уходит в прошлое уступая место бутовым автоконфигурациям).
Я так то не оторванный от реалий идеалист, все могу понять. Просто в ебаном культе меня всю дорогу бесила вот именно эта пиздабольско-демагоговая манера. Нихуя такой дизайн не норма, и SOLIDом там даже близко не пахло. Это просто сложившаяся исторически говенная данность, где мы все варимся. Вот ты хотя бы признал что "да, хуево, но хуй знат как иначе", это я по человечески могу понять. А большинство долбоебов щас будет на говно исходить пытаясь доказать мне что это я просто не преисполнился и должен спринг выучить.
список вставить "мам я долбоёб" 0
>>4130
Тоже мне проблема. Как бы наоборот доучить спринг, уже зная просто джаву
Тоже мне проблема. Как бы наоборот доучить спринг, уже зная просто джаву
>>4517
Сложно только из-за того, что некоторые вещи реализовали раньше, чем в джаве, а потом из в джаве реализовали по другому (замыкания - лямбды) и на стыке языков не очень удобно работать. А так обычный скриптовый язык. Есть аналог шарпового LINQ.
Сложно только из-за того, что некоторые вещи реализовали раньше, чем в джаве, а потом из в джаве реализовали по другому (замыкания - лямбды) и на стыке языков не очень удобно работать. А так обычный скриптовый язык. Есть аналог шарпового LINQ.
Каким же гауном бесполезным джава 25 будет. Хоть бы блядь флексибл конструктор бодис в стейбл завезли, а то пиздец же, одни поломки совместимости и выпиливания.
Java (до нового дерьма) это русский язык от мира программирования. Ну или русский язык это Java среди естественных языков. Так-то
Почему mvnd даёт такой маленький прирост производительности в сравнении с правильно настроенным обычным мавеном? Вормап жи, волшебный JIT жи. Обычный параллельный 16 секунд, демон 12-13.
Кому эти 3 секунды всрались особенно когда добавляется ещё один источник непонятных багов?
Кому эти 3 секунды всрались особенно когда добавляется ещё один источник непонятных багов?
>>4607
Причём я не вижу особо даже обещанной магической инкрементальности. Делаю изменения, компилирую, 13 секунд, не делаю, просто подряд компилирую, всё равно по 13 секунд. Что я делаю не так? Проект маленький относительно, но модулей много, параллелить и инкрементить есть что.
Причём я не вижу особо даже обещанной магической инкрементальности. Делаю изменения, компилирую, 13 секунд, не делаю, просто подряд компилирую, всё равно по 13 секунд. Что я делаю не так? Проект маленький относительно, но модулей много, параллелить и инкрементить есть что.
>>4611
Немного, но часто и этого не делают. Параллельность билда, плагины отпердолить чтобы с параллельностью работали, потом выбирать только нужное через -pl <name> -am. У меня так, мб что-то ещё можно.
Немного, но часто и этого не делают. Параллельность билда, плагины отпердолить чтобы с параллельностью работали, потом выбирать только нужное через -pl <name> -am. У меня так, мб что-то ещё можно.
>>4612
Удачи потом логи компиляции/тестов смотреть на CI
Полтора плагина умеют в параллельные сборки. Остальные тупо тыквят твой билд
Экономия на спичках.
Просто нужно понять, что джава это не про экономию времени и быструю разработку. Тут в порядке вещей билды по часу-полтора и прочие приколдэсы
>Параллельность билда
Удачи потом логи компиляции/тестов смотреть на CI
>плагины отпердолить чтобы с параллельностью работали
Полтора плагина умеют в параллельные сборки. Остальные тупо тыквят твой билд
>потом выбирать только нужное через -pl <name> -am
Экономия на спичках.
Просто нужно понять, что джава это не про экономию времени и быструю разработку. Тут в порядке вещей билды по часу-полтора и прочие приколдэсы
>>4618
Так плагины просто не используй каловые.
А тебе много плагинов нужно? Много нужно классических плагинов, эта портянка с компайл шейд ресурс хуюрс и т.д, они все поддерживают нормально, а те что под проект их как раз и полтора и используется.
Если у тебя сильно горизонтальный проект или вообще монорепа то очень полезно.
А, так ты очередной залётный школодегенерат с фантазиями и проекциями. Ясно.
> Удачи потом логи компиляции/тестов смотреть на CI
Так плагины просто не используй каловые.
> Полтора плагина умеют в параллельные сборки. Остальные тупо тыквят твой билд
А тебе много плагинов нужно? Много нужно классических плагинов, эта портянка с компайл шейд ресурс хуюрс и т.д, они все поддерживают нормально, а те что под проект их как раз и полтора и используется.
> Экономия на спичках.
Если у тебя сильно горизонтальный проект или вообще монорепа то очень полезно.
> Просто нужно понять, что джава это не про экономию времени и быструю разработку. Тут в порядке вещей билды по часу-полтора и прочие приколдэсы
А, так ты очередной залётный школодегенерат с фантазиями и проекциями. Ясно.
>>4621
А других нет. Это же джава
Те, что использую не умеют в параллель
Полезно кому? Выше анон сокрушался, что попал на каловый проект где хуй проссышь как код писать и архитектура говна. По факту этот все верно сказал >>4339 - на работу нужно ходить за деньгами. Если тебе повезло с коллегами и проектом, то может чего-нибудь почерпнешь для себя и научишься новому. Нет? Просто лутай бабки и не отсвечивай. Все эти попытки "улучшить проект" до добра не доводят.
>Так плагины просто не используй каловые.
А других нет. Это же джава
>А тебе много плагинов нужно?
Те, что использую не умеют в параллель
>Если у тебя сильно горизонтальный проект или вообще монорепа то очень полезно.
Полезно кому? Выше анон сокрушался, что попал на каловый проект где хуй проссышь как код писать и архитектура говна. По факту этот все верно сказал >>4339 - на работу нужно ходить за деньгами. Если тебе повезло с коллегами и проектом, то может чего-нибудь почерпнешь для себя и научишься новому. Нет? Просто лутай бабки и не отсвечивай. Все эти попытки "улучшить проект" до добра не доводят.
>>4626
По моему джава это как раз про 100500 способов пёрнуть в трубочку.
А ты хотя б пробовал их настраивать? Или обновлять. Или альтернативы искать. Или хотя бы понять какой конкретно плагин не могёт.
Блядь, ну это другой вопрос, что работнику на говноработе обосновано вола с суровым видом ебать. Тут речь идёт в принципе о том инструмент полезен или нет.
> А других нет. Это же джава
По моему джава это как раз про 100500 способов пёрнуть в трубочку.
> Те, что использую не умеют в параллель
А ты хотя б пробовал их настраивать? Или обновлять. Или альтернативы искать. Или хотя бы понять какой конкретно плагин не могёт.
> Полезно кому? Выше анон сокрушался, что попал на каловый проект где хуй проссышь как код писать и архитектура говна. По факту этот все верно сказал >>4339 - на работу нужно ходить за деньгами. Если тебе повезло с коллегами и проектом, то может чего-нибудь почерпнешь для себя и научишься новому. Нет? Просто лутай бабки и не отсвечивай. Все эти попытки "улучшить проект" до добра не доводят.
Блядь, ну это другой вопрос, что работнику на говноработе обосновано вола с суровым видом ебать. Тут речь идёт в принципе о том инструмент полезен или нет.
>>4627
Зачем? У меня нет цели сделать проект кабана лучше, если я встречаю лишь агрессию и непонимание со стороны команды и руководства. Мне проще плыть по течению, а в свободное время ковыряться во всем этом.
>Или альтернативы искать
Зачем? У меня нет цели сделать проект кабана лучше, если я встречаю лишь агрессию и непонимание со стороны команды и руководства. Мне проще плыть по течению, а в свободное время ковыряться во всем этом.
>>4517
Groovy охуенно сложнее джавы, бтв
Groovy охуенно сложнее джавы, бтв
>>4517
Groovy самый плохой язык программирования, который не пытались сделать плохим умышленно. Поэтому довольно сложно.
Groovy самый плохой язык программирования, который не пытались сделать плохим умышленно. Поэтому довольно сложно.
>>5166
Что в нем такого уж плохого? Просто не надо юзать весь тот безумный объем пиздеца, который туда напихали разрабы, и будет норм.
По сути, можно сказать что джава это подмножество груви. То есть и жава тоже кал говна получается?
Что в нем такого уж плохого? Просто не надо юзать весь тот безумный объем пиздеца, который туда напихали разрабы, и будет норм.
По сути, можно сказать что джава это подмножество груви. То есть и жава тоже кал говна получается?
>>5175
Очень сложный язык с огромным количеством фич, тремя парадигмами и мега фреймворками как ZIO, cats и akka, которые все еще сильнее усложняют и специализируют. На ней пишет очень мало людей, и все по-разному.
В скале много интересных идей, но язык очень непрактичный.
Очень сложный язык с огромным количеством фич, тремя парадигмами и мега фреймворками как ZIO, cats и akka, которые все еще сильнее усложняют и специализируют. На ней пишет очень мало людей, и все по-разному.
В скале много интересных идей, но язык очень непрактичный.
>>5338
Плюс переход с 2ой версии на 3ью, как в питуне...
Плюс переход с 2ой версии на 3ью, как в питуне...
>>4608
Прихожу с обновлениями. Мне напиздели, инкрементальности в мвнд и не было никогда. Зато есть в такари, старичок до сих пор работает. За 7,5 секунд теперь билдится без изменений и 9 с изменениями. 20 немаленьких модулей в проекте.
Ебало градлодебилов которые страдают со скриптобилдами из-за "скорости" (которой нет, потому что первый билд на градле это пиздец, можно чай уходить пить, а когда вернуться видеть build failed) к осмотру.
Прихожу с обновлениями. Мне напиздели, инкрементальности в мвнд и не было никогда. Зато есть в такари, старичок до сих пор работает. За 7,5 секунд теперь билдится без изменений и 9 с изменениями. 20 немаленьких модулей в проекте.
Ебало градлодебилов которые страдают со скриптобилдами из-за "скорости" (которой нет, потому что первый билд на градле это пиздец, можно чай уходить пить, а когда вернуться видеть build failed) к осмотру.
>>5360
Уже разобрался как читать поломанные логи при параллельной сборке модулей и запуске тестов?
Уже разобрался как читать поломанные логи при параллельной сборке модулей и запуске тестов?
>>5388
А что там читать? Вроде всё стабильно. Есть какая-то хуйня что мвнд хуеет когда сильно помник меняешь разом, но mvnd --stop спасает, даже читать не надо ничё, к тому же помник с полунуля ты редко переписываешь.
А что там читать? Вроде всё стабильно. Есть какая-то хуйня что мвнд хуеет когда сильно помник меняешь разом, но mvnd --stop спасает, даже читать не надо ничё, к тому же помник с полунуля ты редко переписываешь.
>>5388
Что вы с этими логами параллельной сборки носитесь? Упал билд - запусти однопоточный билд, делов-то. А если у вас каждый второй билд падает, то проблема не в мавене.
Что вы с этими логами параллельной сборки носитесь? Упал билд - запусти однопоточный билд, делов-то. А если у вас каждый второй билд падает, то проблема не в мавене.
Подскажите, на сколько распространённая практика мультимодульности? У вас лично это используется? Все модули лежат в одной репе или в нескольких разных?
>>5462
Зависит от контекста. Если никакие артефакты наружу не нужно отдавать, то лучше все хранить в одном модуле и разделение сделать на уровне пакетов.
Однажды я попал на проект, где лид обезумел и начал нарезать модули внутри проекта. Когда я увольнялся, в проекте было больше 60 модулей и ни один из них не использовался вне проекта
Зависит от контекста. Если никакие артефакты наружу не нужно отдавать, то лучше все хранить в одном модуле и разделение сделать на уровне пакетов.
Однажды я попал на проект, где лид обезумел и начал нарезать модули внутри проекта. Когда я увольнялся, в проекте было больше 60 модулей и ни один из них не использовался вне проекта
>>5473
Не, речь именно о том, чтобы раздавать. Допустим есть модуль, в котором есть логика, позволяющая добавлять таски в информационную систему. Ты можешь этот модуль приделать к проекту графического приложения десктопного. Можешь приделать к веб-сервису. Можешь приделать к сайту. Добавление такски всегда одно и то же. Но проекты десктопного приложения, веб-сервиса и сайта это разные проекты.
Не, речь именно о том, чтобы раздавать. Допустим есть модуль, в котором есть логика, позволяющая добавлять таски в информационную систему. Ты можешь этот модуль приделать к проекту графического приложения десктопного. Можешь приделать к веб-сервису. Можешь приделать к сайту. Добавление такски всегда одно и то же. Но проекты десктопного приложения, веб-сервиса и сайта это разные проекты.
>>5470
В первую очередь при параллельной сборке демоном вообще нихуя никуда не пишется пока не собралось. Записывается уже после сборки. Наверняка что-то придумали для ошибок раз научились логами управлять, потому что пока я наворачивал эту параллельную сборку я миллион фейлов наловил и всё получалось читать.
В первую очередь при параллельной сборке демоном вообще нихуя никуда не пишется пока не собралось. Записывается уже после сборки. Наверняка что-то придумали для ошибок раз научились логами управлять, потому что пока я наворачивал эту параллельную сборку я миллион фейлов наловил и всё получалось читать.
>>5470
У тебя при паралельном чтении постов, фразы смешиваются и в голове полная каша, которую хрен поймёшь.
>При параллельной сборке у тебя логи пишутся из нескольких потоков в терминал или лог файл на CI и по итогу у тебя там каша. Если билд упадет, то потом хуй разберешься где что зафейлилось
У тебя при паралельном чтении постов, фразы смешиваются и в голове полная каша, которую хрен поймёшь.
>Упал билд - запусти однопоточный билд, делов-то. А если у вас каждый второй билд падает, то проблема не в мавене.
>>6331
Это все блажь и от лукавого. Хуй забей на эти улучшения.
Это все блажь и от лукавого. Хуй забей на эти улучшения.
>>5462
Ты про какие модули спрашиваешь? Про JPMS? Или тупо про какие нибудь мавен-модули?
Мавен проекты на модули обязательно делим - чтоб прям со старта корневой модуль был packaging=pom. Есть ряд монолитных проектов, но на пользу им эта монолитность нихуя не пошла, когда руки дойдут - поделим и их. Вообще, за packaging=jar в корневом помнике впору по рукам бить.
Одно с другим не связано. Разбиение по репам скорее - вопрос организации всяких бранчингов, релизных циклов и прочих процессов. Сама по себе самоцель разносить модули по разным репам обычно не имеет под собой никакого смысла.
Лично у нас - реп под один продукт либо реп под одну команду. Периодически бывает что ряд модулей переезжает в отдельный реп или из репа в реп.
Ты про какие модули спрашиваешь? Про JPMS? Или тупо про какие нибудь мавен-модули?
>У вас лично это используется?
Мавен проекты на модули обязательно делим - чтоб прям со старта корневой модуль был packaging=pom. Есть ряд монолитных проектов, но на пользу им эта монолитность нихуя не пошла, когда руки дойдут - поделим и их. Вообще, за packaging=jar в корневом помнике впору по рукам бить.
>Все модули лежат в одной репе или в нескольких разных?
Одно с другим не связано. Разбиение по репам скорее - вопрос организации всяких бранчингов, релизных циклов и прочих процессов. Сама по себе самоцель разносить модули по разным репам обычно не имеет под собой никакого смысла.
Лично у нас - реп под один продукт либо реп под одну команду. Периодически бывает что ряд модулей переезжает в отдельный реп или из репа в реп.
>>6390
Что за хуйню ты несёшь, долбоёб? Не из тех ли ты дегенератов что в десятых носились по всему интернету и орали о том какое зло instanceof?
> Вообще, за packaging=jar в корневом помнике впору по рукам бить.
Что за хуйню ты несёшь, долбоёб? Не из тех ли ты дегенератов что в десятых носились по всему интернету и орали о том какое зло instanceof?
>>6396
Нет, не из тех. Против instanceof ничего не имею. А вот из-за долбоебизма предтеч, не сделавших элементарную вещь которая упростила бы все будущие рефакторинги, пару раз приходилось расхлебывать последствия.
Ты че порвался то? Руки зудят?
Нет, не из тех. Против instanceof ничего не имею. А вот из-за долбоебизма предтеч, не сделавших элементарную вещь которая упростила бы все будущие рефакторинги, пару раз приходилось расхлебывать последствия.
Ты че порвался то? Руки зудят?
>>6407
Каким образом превентивное разделение на модули упростит хоть какие-то рефакторинги? Максимально поверхностная хуйня.
Каким образом превентивное разделение на модули упростит хоть какие-то рефакторинги? Максимально поверхностная хуйня.
>>6408
Ты где про превентивные модули вычитал в фразе "за packaging=jar в корневом помнике впору по рукам бить"? Нет буквально ничего сложного в том, чтобы сделать корневой помник packaging=pom. Какие нахуй преждевременные модули?
А ты че - никогда не рефачил полотнища монолитного помника, где намешаны и депенденси с их версиями, и стопятцот плагинов делающих все - от стайлчекинга до билда конечных сборок через какой нибудь ассемблай с антовыми вставками? Может быть правил что нибудь в таком месиве?
С корневым помником у тебя хотя бы есть инструмент, через который ты можешь зависимости от билд пайплайна быстро и легко отделить, для начала. А если есть скилл, можно вообще весь билд пайплайн аккуратненько в руте по профайлам разложить так, что все помники по читабельности будут по читабельности грыдле давать пососать.
>превентивное разделение на модули
Ты где про превентивные модули вычитал в фразе "за packaging=jar в корневом помнике впору по рукам бить"? Нет буквально ничего сложного в том, чтобы сделать корневой помник packaging=pom. Какие нахуй преждевременные модули?
>упростит хоть какие-то рефакторинги?
А ты че - никогда не рефачил полотнища монолитного помника, где намешаны и депенденси с их версиями, и стопятцот плагинов делающих все - от стайлчекинга до билда конечных сборок через какой нибудь ассемблай с антовыми вставками? Может быть правил что нибудь в таком месиве?
С корневым помником у тебя хотя бы есть инструмент, через который ты можешь зависимости от билд пайплайна быстро и легко отделить, для начала. А если есть скилл, можно вообще весь билд пайплайн аккуратненько в руте по профайлам разложить так, что все помники по читабельности будут по читабельности грыдле давать пососать.
>>6423
Ты куда код будешь писать, когда сделаешь корень pom'ом, долбоёб? В один из modules. Или в твоём случае единственный, что терминальная стадия шизофрении.
Каким образом это к твоему высеру на jar в руте относится? Каким образом перетаскивание всего этого на уровень ниже поможет?
У тебя этим занимается разделение блоков build и dependencies. Ей богу олигофрен.
О каком скилле ты высираешь, если у тебя модульность выполняет задачу разноса зависимостей и билда на разные файлы? Высер про градл это вообще пиздец. С каких пор блядь градл стал читаемее мавена? Он блядь всегда был нечитаем, это его главный недостаток сука был всегда.
Блядь, какой же идиот, постоянно приходит в тред и несёт такую хуйню что появляются вопросы а не ии ли это серет. Буквально тот самый омеган что пытается "за компанию" в разговор встрять и несёт околесицу от которой всем (кроме него самого) стыдно.
> Ты где про превентивные модули вычитал в фразе "за packaging=jar в корневом помнике впору по рукам бить"? Нет буквально ничего сложного в том, чтобы сделать корневой помник packaging=pom. Какие нахуй преждевременные модули?
Ты куда код будешь писать, когда сделаешь корень pom'ом, долбоёб? В один из modules. Или в твоём случае единственный, что терминальная стадия шизофрении.
> А ты че - никогда не рефачил полотнища монолитного помника, где намешаны и депенденси с их версиями, и стопятцот плагинов делающих все - от стайлчекинга до билда конечных сборок через какой нибудь ассемблай с антовыми вставками? Может быть правил что нибудь в таком месиве?
Каким образом это к твоему высеру на jar в руте относится? Каким образом перетаскивание всего этого на уровень ниже поможет?
> через который ты можешь зависимости от билд пайплайна быстро и легко отделить, для начала.
У тебя этим занимается разделение блоков build и dependencies. Ей богу олигофрен.
> А если есть скилл, можно вообще весь билд пайплайн аккуратненько в руте по профайлам разложить так, что все помники по читабельности будут по читабельности грыдле давать пососать.
О каком скилле ты высираешь, если у тебя модульность выполняет задачу разноса зависимостей и билда на разные файлы? Высер про градл это вообще пиздец. С каких пор блядь градл стал читаемее мавена? Он блядь всегда был нечитаем, это его главный недостаток сука был всегда.
Блядь, какой же идиот, постоянно приходит в тред и несёт такую хуйню что появляются вопросы а не ии ли это серет. Буквально тот самый омеган что пытается "за компанию" в разговор встрять и несёт околесицу от которой всем (кроме него самого) стыдно.
>>6444
Да хули я распинаюсь блять перед каким то двачевым недоноском. У меня на проекте ты бы тише травы ниже воды сидел, чмо, либо с переломанными руками. Не хошь вести конструктивный диалог - пошел нахуй. Можешь слив еще засчитать как вы, двачевые дегенераты любите.
>долбоёб
>терминальная стадия шизофрении.
>идиот
>олигофрен
Да хули я распинаюсь блять перед каким то двачевым недоноском. У меня на проекте ты бы тише травы ниже воды сидел, чмо, либо с переломанными руками. Не хошь вести конструктивный диалог - пошел нахуй. Можешь слив еще засчитать как вы, двачевые дегенераты любите.
>>6457
Привыкай пропускать мимо ушей оскорбления, ты же на сосаче, а то всегда придётся грызтись вместо попыток в разговор по сути. К тому же заслужил, ты ж несёшь хуйню полную.
Привыкай пропускать мимо ушей оскорбления, ты же на сосаче, а то всегда придётся грызтись вместо попыток в разговор по сути. К тому же заслужил, ты ж несёшь хуйню полную.
>>6467
Да мне похуй, че решил для себя то и несу. Шарю свой опыт анону, который задал вопрос, ни больше ни меньше. Мне ни тепло ни холодно от того, что недоносок двачевый мой пойнт не выкупил - у меня на проекте помники от этого свой пэкеджинг не поменяют.
Да мне похуй, че решил для себя то и несу. Шарю свой опыт анону, который задал вопрос, ни больше ни меньше. Мне ни тепло ни холодно от того, что недоносок двачевый мой пойнт не выкупил - у меня на проекте помники от этого свой пэкеджинг не поменяют.
>>6480
Какой опыт? Притащил хуйню какую-то уровня инстансоф зло, когда спросили за неё разнылся "мам миня аскарбляют(((".
Какой опыт? Притащил хуйню какую-то уровня инстансоф зло, когда спросили за неё разнылся "мам миня аскарбляют(((".
>>6486
Да ты шиз блять, тебе уже кругом гуки на деревьях мерещатся с инстанс офами. Сходи уже в окно проветрись, траву пощупай.
Да ты шиз блять, тебе уже кругом гуки на деревьях мерещатся с инстанс офами. Сходи уже в окно проветрись, траву пощупай.
>>6489
Да ничё не мерещится, отчётливо вижу посты этого гука с пакейджинг=джар перед собой.
Да ничё не мерещится, отчётливо вижу посты этого гука с пакейджинг=джар перед собой.
71 Кб, 721x718В общем, ситуация такая, у меня две бд - эластик и постгря и из-за особенностей эластика мне нада сделать сагу.
Предметная область база знаний, записки там и тд, ничего интересного.
Долго лежал, плевал в потолок, как бы это получше организовать архитектурно. В итоге пришел к такой структуре:
Есть базовая табличка notes, куда я кладу иммутабельные или уникальные поля, типа владельца, пути до заметки и прочей поеботы. Эта заметка так или иначе имеет связь с состоянием.
Состояние - это жизненный цикл заметки, типа `CREATE -> UPDATE -> UPDATE -> ...`.
Т.е. если я захочу изменить контент внутри заметки мне сначала нада создать новый стейт в таблице note_states и перепривязать (закоммитить) это новое состояние заместо старого в таблицу notes. Поскольку у меня есть два состояния и новое и старое, предполагаю, что тут вполне можно ебануть оптимистик локи.
Так вот, тут я думаю и вступает в дело сага. Т.е. я сначала создаю новый стейт. А потом запись, что надо бы закоммитить вместо старого стейта, на новый такую-то запись в notes. А потом отправляю это в кафку, которая эвент создаст.
Теперь, в saga_logs будут созадаваться записи типа CREATE IN ELASTIC -> REINDEX -> COMMIT IN ELASTIC -> COMMIT IN DB -> DONE
На любом этапе, если выяснится, что state_old_id не совпадает с тем, что лежит в notes или просто произошел пиздец, можно легко откатить все действия.
Также я планирую создавать в elastic под каждый стейт новый документ и наделять его состоянием типа COMMITED/UNCOMMITED. Таким образом я не не закорапчу поиск, поскольку все незакоммиченные можно просто отфильтровать да и вообще можно будет удалять незакоммиченные документы. Также сначала получается будут этапы создания документов, а потом два этапа коммита сначала в эластике, а потом в бд, что +- атомарно.
Насколько ебанутая схема и далеко от бест практис?
Предметная область база знаний, записки там и тд, ничего интересного.
Долго лежал, плевал в потолок, как бы это получше организовать архитектурно. В итоге пришел к такой структуре:
Есть базовая табличка notes, куда я кладу иммутабельные или уникальные поля, типа владельца, пути до заметки и прочей поеботы. Эта заметка так или иначе имеет связь с состоянием.
Состояние - это жизненный цикл заметки, типа `CREATE -> UPDATE -> UPDATE -> ...`.
Т.е. если я захочу изменить контент внутри заметки мне сначала нада создать новый стейт в таблице note_states и перепривязать (закоммитить) это новое состояние заместо старого в таблицу notes. Поскольку у меня есть два состояния и новое и старое, предполагаю, что тут вполне можно ебануть оптимистик локи.
Так вот, тут я думаю и вступает в дело сага. Т.е. я сначала создаю новый стейт. А потом запись, что надо бы закоммитить вместо старого стейта, на новый такую-то запись в notes. А потом отправляю это в кафку, которая эвент создаст.
Теперь, в saga_logs будут созадаваться записи типа CREATE IN ELASTIC -> REINDEX -> COMMIT IN ELASTIC -> COMMIT IN DB -> DONE
На любом этапе, если выяснится, что state_old_id не совпадает с тем, что лежит в notes или просто произошел пиздец, можно легко откатить все действия.
Также я планирую создавать в elastic под каждый стейт новый документ и наделять его состоянием типа COMMITED/UNCOMMITED. Таким образом я не не закорапчу поиск, поскольку все незакоммиченные можно просто отфильтровать да и вообще можно будет удалять незакоммиченные документы. Также сначала получается будут этапы создания документов, а потом два этапа коммита сначала в эластике, а потом в бд, что +- атомарно.
Насколько ебанутая схема и далеко от бест практис?
>>6492
Может проще навесить поисковые индексы на простгрю? Ты же эластику ради полнотекстового поиска хочешь?
Может проще навесить поисковые индексы на простгрю? Ты же эластику ради полнотекстового поиска хочешь?
>>6492
А для тебя прям критически важна согласованность поискового индекса с данными в базе? Может ну ее эту сагу? Ну выдаст те индекс несуществующую в базе сущность в моменте - выкинешь ее из выборки перед отдачей и норм. Гугл же тоже твой бложек не сразу проиндексирует.
А для тебя прям критически важна согласованность поискового индекса с данными в базе? Может ну ее эту сагу? Ну выдаст те индекс несуществующую в базе сущность в моменте - выкинешь ее из выборки перед отдачей и норм. Гугл же тоже твой бложек не сразу проиндексирует.
>>6577
Проблема в том что несогласованность будет только расти. А чтобы не росла нужно отменять, а лучшее время для отмены это сразу как только было понято что будет несогласованность, т.е. в саге.
Проблема в том что несогласованность будет только расти. А чтобы не росла нужно отменять, а лучшее время для отмены это сразу как только было понято что будет несогласованность, т.е. в саге.
>>6492
Когда нужно коммитить в две базы, то просто пушат месседж в кафку, а оттуда уже читают и пишут в постгрю и прочие эластики. Ты просто не читал кабана, чел.. Ты слаб и тебе нужно тренироваться
Когда нужно коммитить в две базы, то просто пушат месседж в кафку, а оттуда уже читают и пишут в постгрю и прочие эластики. Ты просто не читал кабана, чел.. Ты слаб и тебе нужно тренироваться
>>6608
Ну она будет расти если ты совсем хуй забьешь. Я просто веду к тому, что индекс можно и независимо от отдельных коммитов в дб делать. Грубо говоря: пусть круд крудит на базе + каким то образом ведет учет того, какие сущности следует переиндексировать (хотя бы теми же эвентами в кафке, или флагом в таблице - не суть). А параллельно с крудом - по скедулу, например - выгребаешь все что нужно индексировать и индексируешь.
Ну она будет расти если ты совсем хуй забьешь. Я просто веду к тому, что индекс можно и независимо от отдельных коммитов в дб делать. Грубо говоря: пусть круд крудит на базе + каким то образом ведет учет того, какие сущности следует переиндексировать (хотя бы теми же эвентами в кафке, или флагом в таблице - не суть). А параллельно с крудом - по скедулу, например - выгребаешь все что нужно индексировать и индексируешь.
>>6629
Какая глава? Там про сагу не слова, а 2PC не подходит, потому что это эластик.
>>6637
Хороший вариант, у меня получается, если пользователь сохранил новое состояние заметки, дождавшись подтверждения, то перезагрузив страницу он будет видить старое состояние страницы, до тех пор, пока не будет завершена индексация. В твоем варианте он сразу увидит нормальное состояние, но поиск будет выдывать иногда бред, пока не будет завершена индексация. По сути надо выбрать, где бы наебать пользователя, навернооое твой вариант все таки лучше.
Думаю оставить note_states, поскольку я хотел пристроить это также для функционала сохранения истории и отката к прошлым версиям.
Табличка commits, не нужна, а saga_logs по сути просто логи будет вести.
Т.е. в итоге, я создаю запись в note_states и коммичу её в notes и меняю поле indexed на false. Потом сабмичу эвент в кафку, мол надо заиндексировать такой-то note_states.id в такой-то notes.id с бэкофом.
Теперь она будет долбится до победного, пока не закончаться попытки или state_id сменится на другой. Также можно делать
`update notes set indexed=true where id=? and commit_to=?` и ну гарантировать в какой-то степени, что не будет ABA проблемы, типа когда во время индексации пользователь обновит табличку (false -> false), и индексатор запишет true = false -> false -> true, хотя в итоге должно быть false.
В сущности вся разница будет только в том, что я созаю индивидуальную тасочку для каждой индексации, а у тебя будет большая такая таска для всех записок сразу. Хрен знает что лучше, но я хотел с кафкой поработать хоть немного, поэтому выберу первый вариант. И пасиба за рекомендацию~
>Ты просто не читал кабана, чел..
Какая глава? Там про сагу не слова, а 2PC не подходит, потому что это эластик.
>>6637
Хороший вариант, у меня получается, если пользователь сохранил новое состояние заметки, дождавшись подтверждения, то перезагрузив страницу он будет видить старое состояние страницы, до тех пор, пока не будет завершена индексация. В твоем варианте он сразу увидит нормальное состояние, но поиск будет выдывать иногда бред, пока не будет завершена индексация. По сути надо выбрать, где бы наебать пользователя, навернооое твой вариант все таки лучше.
Думаю оставить note_states, поскольку я хотел пристроить это также для функционала сохранения истории и отката к прошлым версиям.
Табличка commits, не нужна, а saga_logs по сути просто логи будет вести.
Т.е. в итоге, я создаю запись в note_states и коммичу её в notes и меняю поле indexed на false. Потом сабмичу эвент в кафку, мол надо заиндексировать такой-то note_states.id в такой-то notes.id с бэкофом.
Теперь она будет долбится до победного, пока не закончаться попытки или state_id сменится на другой. Также можно делать
`update notes set indexed=true where id=? and commit_to=?` и ну гарантировать в какой-то степени, что не будет ABA проблемы, типа когда во время индексации пользователь обновит табличку (false -> false), и индексатор запишет true = false -> false -> true, хотя в итоге должно быть false.
В сущности вся разница будет только в том, что я созаю индивидуальную тасочку для каждой индексации, а у тебя будет большая такая таска для всех записок сразу. Хрен знает что лучше, но я хотел с кафкой поработать хоть немного, поэтому выберу первый вариант. И пасиба за рекомендацию~
>>6733
Ты блин, так сказал... как отрезал нах. "Поиск будет выдавать бред"... Ну гугл тащемто тоже иногда выдает бред. На это можно двояко смотреть. Обязательная перестройка индекса на каждый апдейт твоих ноутсов может быть как бенефитом архитектуры, так и изьяном. Второе возможно если у тебя эти ноутсы большие и часто обновляются - тогда апдейт индекса будет отжирать у тебя производительность - если есть вебморда, возможно она начнет лагать. В то время как откапли ты перестройку индекса, сделай ее отдельным батчем раз в минуту, и тогда если за минуту чувак накидал те пять обновлений, индекс один хер перестроится один раз по последнему апдейту, а чувак не факт что что-то заметит, либо ему будет похуй.
Ты блин, так сказал... как отрезал нах. "Поиск будет выдавать бред"... Ну гугл тащемто тоже иногда выдает бред. На это можно двояко смотреть. Обязательная перестройка индекса на каждый апдейт твоих ноутсов может быть как бенефитом архитектуры, так и изьяном. Второе возможно если у тебя эти ноутсы большие и часто обновляются - тогда апдейт индекса будет отжирать у тебя производительность - если есть вебморда, возможно она начнет лагать. В то время как откапли ты перестройку индекса, сделай ее отдельным батчем раз в минуту, и тогда если за минуту чувак накидал те пять обновлений, индекс один хер перестроится один раз по последнему апдейту, а чувак не факт что что-то заметит, либо ему будет похуй.
>>6749
Хмм, может тогда совместить два подхода? Сделать большую таску раз в 5 минут и дать кнопочку пользователю, мол переиндексировать прям счас..
Хмм, может тогда совместить два подхода? Сделать большую таску раз в 5 минут и дать кнопочку пользователю, мол переиндексировать прям счас..
Что могут на собесе спросить про кафку? У меня на прошлом месте была кафка, но я ее просто отключал при дебаге, чтобы не мешалась, чё она делала хз. Что можно рассказать про нее? Как ее используют в реальности? Вот так?
@Autowired
private final KafkaTemplate<String, String> kafkaTemplate;
public void send(String topic, String message) {
kafkaTemplate.send(topic, message);
}
И вот тут шлем в нее и читаем
@RestController
public class MessageController {
private final Sender sender;
private final MessageConsumer consumer;
public MessageController(Sender sender, MessageConsumer consumer) {
this.sender = sender;
this.consumer = consumer;
}
@GetMapping("/send")
public ResponseEntity<String> sendMessage(@RequestParam String topic, @RequestParam String message) {
System.out.println("Sent message: " + message);
sender.send(topic, message);
consumer.listen(message);
System.out.println("Sent message: " + message);
return ResponseEntity.ok("Message sent to topic: " + topic);
}
Похоже на реальность?
@Autowired
private final KafkaTemplate<String, String> kafkaTemplate;
public void send(String topic, String message) {
kafkaTemplate.send(topic, message);
}
И вот тут шлем в нее и читаем
@RestController
public class MessageController {
private final Sender sender;
private final MessageConsumer consumer;
public MessageController(Sender sender, MessageConsumer consumer) {
this.sender = sender;
this.consumer = consumer;
}
@GetMapping("/send")
public ResponseEntity<String> sendMessage(@RequestParam String topic, @RequestParam String message) {
System.out.println("Sent message: " + message);
sender.send(topic, message);
consumer.listen(message);
System.out.println("Sent message: " + message);
return ResponseEntity.ok("Message sent to topic: " + topic);
}
Похоже на реальность?
Что могут на собесе спросить про кафку? У меня на прошлом месте была кафка, но я ее просто отключал при дебаге, чтобы не мешалась, чё она делала хз. Что можно рассказать про нее? Как ее используют в реальности? Вот так?
@Autowired
private final KafkaTemplate<String, String> kafkaTemplate;
public void send(String topic, String message) {
kafkaTemplate.send(topic, message);
}
И вот тут шлем в нее и читаем
@RestController
public class MessageController {
private final Sender sender;
private final MessageConsumer consumer;
public MessageController(Sender sender, MessageConsumer consumer) {
this.sender = sender;
this.consumer = consumer;
}
@GetMapping("/send")
public ResponseEntity<String> sendMessage(@RequestParam String topic, @RequestParam String message) {
System.out.println("Sent message: " + message);
sender.send(topic, message);
consumer.listen(message);
System.out.println("Sent message: " + message);
return ResponseEntity.ok("Message sent to topic: " + topic);
}
Похоже на реальность?
@Autowired
private final KafkaTemplate<String, String> kafkaTemplate;
public void send(String topic, String message) {
kafkaTemplate.send(topic, message);
}
И вот тут шлем в нее и читаем
@RestController
public class MessageController {
private final Sender sender;
private final MessageConsumer consumer;
public MessageController(Sender sender, MessageConsumer consumer) {
this.sender = sender;
this.consumer = consumer;
}
@GetMapping("/send")
public ResponseEntity<String> sendMessage(@RequestParam String topic, @RequestParam String message) {
System.out.println("Sent message: " + message);
sender.send(topic, message);
consumer.listen(message);
System.out.println("Sent message: " + message);
return ResponseEntity.ok("Message sent to topic: " + topic);
}
Похоже на реальность?
>>6774
Представь себе - ты двачер. Открываешь блокнот для заметок а там кнопка "перестроить индекс". Твое лицо в этот момент?
Представь себе - ты двачер. Открываешь блокнот для заметок а там кнопка "перестроить индекс". Твое лицо в этот момент?
>>6807
Нуу, можно абстрактно это как-нибудь обозвать. Типа "синхронизировать". Что синхронизировать, с кем синхронизировать вопрос третьестепенный. В общем спасиба еще раз, надо по быстренькому хоть что-то накидать..
Нуу, можно абстрактно это как-нибудь обозвать. Типа "синхронизировать". Что синхронизировать, с кем синхронизировать вопрос третьестепенный. В общем спасиба еще раз, надо по быстренькому хоть что-то накидать..
Это же стандартное решение. Получение сущности по id должно возвращать всегда последнюю версию, но поиск по изменённым полям может немного запаздывать.
Та же монга так сделана, да и многие другие движки баз тоже.
мимо
Та же монга так сделана, да и многие другие движки баз тоже.
мимо
>>6846
Я те просто намекнул, что двачеру какбэ во первых похуй, во вторых не его собачье дело, че у тебя там за кухня на бэкенде творится. Ты щас петоводишь, молодой и шутливый - у тебя еще есть опция попытаться решить проблему типично программерским методом. А тем временем реальный проект может быть упорот по UI/UX, и вообще вся галера ориентирована на клиента. Тогда тебе эту странную кнопку попросту не дадут добавить.
Удачи.
Я те просто намекнул, что двачеру какбэ во первых похуй, во вторых не его собачье дело, че у тебя там за кухня на бэкенде творится. Ты щас петоводишь, молодой и шутливый - у тебя еще есть опция попытаться решить проблему типично программерским методом. А тем временем реальный проект может быть упорот по UI/UX, и вообще вся галера ориентирована на клиента. Тогда тебе эту странную кнопку попросту не дадут добавить.
Удачи.
>>6774
Перестройка чего-либо по таймеру это всегда дегенеративный подход ибо ты регулярно будешь обрабатывать данные что не нужно обрабатывать никоим боком. Нужно реагировать.
мимо
Перестройка чего-либо по таймеру это всегда дегенеративный подход ибо ты регулярно будешь обрабатывать данные что не нужно обрабатывать никоим боком. Нужно реагировать.
мимо
>>7299
Ну с моей т.з. это просто откладывание момента обработки, причем централизованным способом. Что-то типа гц, который по кд собирает мусор. Почему этот подход дегенеративный мне не совсем понятно, раскрой мысль.
В принципе-то, если разбивать все на сингл таски и пихать это в кафку, то можно более точечно контролировать потребление, поскольку это очередь же.
Ну с моей т.з. это просто откладывание момента обработки, причем централизованным способом. Что-то типа гц, который по кд собирает мусор. Почему этот подход дегенеративный мне не совсем понятно, раскрой мысль.
В принципе-то, если разбивать все на сингл таски и пихать это в кафку, то можно более точечно контролировать потребление, поскольку это очередь же.
>>7316
Так гц (по крайней мере классические, не знаю про новые подходы типо zgc, мб там что-то поменялось коли обещают независимость от размера кучи кала) тоже дегенеративен. Обойти всю кучу чтобы понять что отвалилось, вместо того чтобы сигналить когда что отваливается, ну не пиздец ли же.
Так гц (по крайней мере классические, не знаю про новые подходы типо zgc, мб там что-то поменялось коли обещают независимость от размера кучи кала) тоже дегенеративен. Обойти всю кучу чтобы понять что отвалилось, вместо того чтобы сигналить когда что отваливается, ну не пиздец ли же.
>>7318
Зато это значительно упрощает работу с памятью для языков. Трейдофф между простотой и перфомансом/красотой. Для тебя я так понимаю пик эволюции обработки мусора - это борроу чекер или эти умные указатели?
Зато это значительно упрощает работу с памятью для языков. Трейдофф между простотой и перфомансом/красотой. Для тебя я так понимаю пик эволюции обработки мусора - это борроу чекер или эти умные указатели?
>>7299
Иногда приходится делать задания по таймеру. Иного пути нет. Например, я делал интеграцию с системой, в которой в таблице в базе данных выставлялся статус что такой-то документ готов к отправке по api и мне нужно было его считать, сформировать запрос и отправить по api. Это нельзя никак решить иначе кроме как поллингом по таймеру где будет селект из этой таблицы. Никто никакого события тебе генерить не будет и колбеков ни каких вызывать тоже, обычная база данных MySQL 5.5 и в ней таблица. Всё. Делай.
Иногда приходится делать задания по таймеру. Иного пути нет. Например, я делал интеграцию с системой, в которой в таблице в базе данных выставлялся статус что такой-то документ готов к отправке по api и мне нужно было его считать, сформировать запрос и отправить по api. Это нельзя никак решить иначе кроме как поллингом по таймеру где будет селект из этой таблицы. Никто никакого события тебе генерить не будет и колбеков ни каких вызывать тоже, обычная база данных MySQL 5.5 и в ней таблица. Всё. Делай.
>>7558
Э слыш, ты тут со своими реальными задачами по разбору куч говна не вылезай, здесь солидные фантазёры.
Э слыш, ты тут со своими реальными задачами по разбору куч говна не вылезай, здесь солидные фантазёры.
>>7568
Тащемто нет. Я прекрасно осознаю что есть ситуации в которых локально человек нихуя не сможет сделать. Смысл был в том что глобально всегда есть решение лучше, и подумать над тем на самом ли деле ты ограничен в возможностях или можно сделать получше стоит.
тот самый мимокрокодил
Тащемто нет. Я прекрасно осознаю что есть ситуации в которых локально человек нихуя не сможет сделать. Смысл был в том что глобально всегда есть решение лучше, и подумать над тем на самом ли деле ты ограничен в возможностях или можно сделать получше стоит.
тот самый мимокрокодил
11 Кб, 654x142>>7619
Мне кажется это нейронка.
>>7617
Ну жаба действительно не позволяет перегружать ==, причем чисто принципиально, поэтому для структурного сравнения, тебе надо equals. Но этот метод можно сгенерировать, через тот же record.
Не понимаю к чему тут вообще приплели делегаты, поскольку функциональный тип, как известно, одно из немногих исключений,к который в теории типов принципиально не обладает свойством эквивалентности = его нельзя сравинвать и к нему ты не сможешь написать корректный equals метод.
Ну и ты можешь неявно наследовать, пик.
Мне кажется это нейронка.
>>7617
Ну жаба действительно не позволяет перегружать ==, причем чисто принципиально, поэтому для структурного сравнения, тебе надо equals. Но этот метод можно сгенерировать, через тот же record.
Не понимаю к чему тут вообще приплели делегаты, поскольку функциональный тип, как известно, одно из немногих исключений,к который в теории типов принципиально не обладает свойством эквивалентности = его нельзя сравинвать и к нему ты не сможешь написать корректный equals метод.
Ну и ты можешь неявно наследовать, пик.
>>7621
В какой ещё теории типов? В твоей влажной?
По моему он скорее не нужен. Написать то наоборот просто, сравнивай класс и всё.
> в теории типов
В какой ещё теории типов? В твоей влажной?
> его нельзя сравинвать и к нему ты не сможешь написать корректный equals метод.
По моему он скорее не нужен. Написать то наоборот просто, сравнивай класс и всё.
>>7617
Дружно ждем вальхаллы - там скорее всего чето такое завезут. А вообще, тема интересная, много экспериментировал на нее.
Вот уж на что похуй так похуй. Любая такая несовместимость решается простым переходом от прямой ссылки к метод-референсу на похуях.
>сравнение по ссылкам vs эквивалентность
Дружно ждем вальхаллы - там скорее всего чето такое завезут. А вообще, тема интересная, много экспериментировал на нее.
>делегаты vs функциональные интерфейсы
Вот уж на что похуй так похуй. Любая такая несовместимость решается простым переходом от прямой ссылки к метод-референсу на похуях.
>>7621
Замыкания можно было бы сравнить, в теории... но на практике - хуй, конечно.
>его нельзя сравинвать и к нему ты не сможешь написать корректный equals метод.
Замыкания можно было бы сравнить, в теории... но на практике - хуй, конечно.
53 Кб, 731x265>>7622
Хм.. Ну да, есть же альфа эквивалентность, ну и eta conversion, хотя имплементация подобного.. Ну немного затруднительна.
Этого не хватит, лямбда же может захватить что-то с разными значениями. Причем более того, тебе нигде в спеке не гарантируется, что лямбды и дальше будут имплементироваться через анонимные классы и также там есть приписка, что это вэлью классы, и поэтому пожалуйста, не используйте лямбды в synchronized и не используйте с ними ==, посколку они могут в будущем не иметь identity.
>>7629
Ну да, но это в принципе и правда не нужно. Мне просто непонятно как мы от сравнения пришли к делегатам..
>В какой ещё теории типов?
Хм.. Ну да, есть же альфа эквивалентность, ну и eta conversion, хотя имплементация подобного.. Ну немного затруднительна.
>сравнивай класс и всё
Этого не хватит, лямбда же может захватить что-то с разными значениями. Причем более того, тебе нигде в спеке не гарантируется, что лямбды и дальше будут имплементироваться через анонимные классы и также там есть приписка, что это вэлью классы, и поэтому пожалуйста, не используйте лямбды в synchronized и не используйте с ними ==, посколку они могут в будущем не иметь identity.
>>7629
Ну да, но это в принципе и правда не нужно. Мне просто непонятно как мы от сравнения пришли к делегатам..
>>7631
Мне - очень нужно(
Но мне не повезло, потому что лямбды в джаве на уровне байткода вместо каноничных анонимных классов (в которые даже можно откатиться с помощью какой нить ретролямбды) выполнены в виде метафакторно-бутстрапной хрени на инвокдинамиках, и я никак не могу сгенерить для инстанса лямбды equals... а как сука хочется...
>это в принципе и правда не нужно
Мне - очень нужно(
Но мне не повезло, потому что лямбды в джаве на уровне байткода вместо каноничных анонимных классов (в которые даже можно откатиться с помощью какой нить ретролямбды) выполнены в виде метафакторно-бутстрапной хрени на инвокдинамиках, и я никак не могу сгенерить для инстанса лямбды equals... а как сука хочется...
>>7633
А зачем, если не секрет? Просто не представляю даже задачу, где это может понадобится.
А зачем, если не секрет? Просто не представляю даже задачу, где это может понадобится.
>>7634
Долго рассказывать. Делал я просто один экспериментальный тул... и все нравится в нем, но лямбды сука всю мазу ломают вот этой вот своей особенностью...
Долго рассказывать. Делал я просто один экспериментальный тул... и все нравится в нем, но лямбды сука всю мазу ломают вот этой вот своей особенностью...
>>7670
Это местный шизик.
Это местный шизик.
37 Кб, 604x453>>7621
Всё это как водится, был пиздеж.
В теории функциональные типы прекрасно сравниваются: если для любой комбинации входных параметров, они выдают одинаковый результат, то типы эквивалентны. Просто на практике такую проверку эквивалентности, за разумное время, реализовать пока не получается. Но в теории всё как раз работает.
>функциональный тип, как известно, одно из немногих исключений,к который в теории типов принципиально не обладает свойством эквивалентности
Всё это как водится, был пиздеж.
В теории функциональные типы прекрасно сравниваются: если для любой комбинации входных параметров, они выдают одинаковый результат, то типы эквивалентны. Просто на практике такую проверку эквивалентности, за разумное время, реализовать пока не получается. Но в теории всё как раз работает.
>>7761
Ну да, ты прав, я сам про енто написал в следующем посте. Просто предположил из основания, что Eq тайпкласс в хачкеле не сделан для стрелок, ну и вот чет предположение построил.. Давно все таки теорию не пересматривал, год прошёл уже.. эх, даже грустно что-то..
Ну да, ты прав, я сам про енто написал в следующем посте. Просто предположил из основания, что Eq тайпкласс в хачкеле не сделан для стрелок, ну и вот чет предположение построил.. Давно все таки теорию не пересматривал, год прошёл уже.. эх, даже грустно что-то..
>>7794
Там же, где и юбочку.
Там же, где и юбочку.
293 Кб, 2728x1229Сап, подскажите по зарплатам. Я, имея 2 года опыта, когда устраивался в компанию, запрашивал 100к. Несколько месяцев уже работаю, но корёжит от мыслей, что мог больше запросить. На хабре вообще заоблачные цифры, хотя там в фильтрах нельзя указать количество лет опыта, только ебанутые термины типа джун мидл, я судя по нему меньше джуна получаю. Однако я из Беларуси, тут поскромнее зарплаты, но не настолько же. Может ли работадатель спустя 9 месяцев на перформанс ревью зп где-то на 60% поднять или только работу новую искать? Хотя я даже хз 60% это я опять мелочусь или дохуя хочу
>>7840
мне работодатель на перфоманс ревью только хуй за щеку поднял пока что
мне работодатель на перфоманс ревью только хуй за щеку поднял пока что
>>7761
Это в общем случае невозможно из-за проблемы остановки.
>Просто на практике такую проверку эквивалентности, за разумное время, реализовать пока не получается. Но в теории всё как раз работает.
Это в общем случае невозможно из-за проблемы остановки.
>>7850
Да чё ты этого школьника слушаешь. Кто заставляет его сравнивать по поведению? По непосредственному коду (ну и замыканиям, хули, хотя это выглядит как какой-то сахар который в типы не лезет) сравнить и всё, в реальности даже код сравнивать не надо потому что есть классы. Только это никому не нужно. Нахуй блядь сравнивать лямбды?
Да чё ты этого школьника слушаешь. Кто заставляет его сравнивать по поведению? По непосредственному коду (ну и замыканиям, хули, хотя это выглядит как какой-то сахар который в типы не лезет) сравнить и всё, в реальности даже код сравнивать не надо потому что есть классы. Только это никому не нужно. Нахуй блядь сравнивать лямбды?
>>7876
Проблема такого подхода в том, что если в тупую сравнивать, то лямбды типа
_ -> 1 + 9
_ -> 5 + 5
Будут ну совершенно разными и как их вообще можно сравнивать-то
А это предложение еще лучше, поскольку даже полностью идентичные лямбды, но созданные в разных местах будут иметь разные классы.
В общем смысле, наверное надо привести к нормальной форме сначала, если нормальные формы совпадают, то они эквивалентны.
>По непосредственному коду
Проблема такого подхода в том, что если в тупую сравнивать, то лямбды типа
_ -> 1 + 9
_ -> 5 + 5
Будут ну совершенно разными и как их вообще можно сравнивать-то
>даже код сравнивать не надо потому что есть классы
А это предложение еще лучше, поскольку даже полностью идентичные лямбды, но созданные в разных местах будут иметь разные классы.
В общем смысле, наверное надо привести к нормальной форме сначала, если нормальные формы совпадают, то они эквивалентны.
>>8025
Ну и?
Нахуй тебе их вообще сравнивать?
> Будут ну совершенно разными
Ну и?
> и как их вообще можно сравнивать-то
Нахуй тебе их вообще сравнивать?
>>8026
Это же не так.
Я не тот челик, но вон та же идея решала эту задачу для поиска дубликации кода.
>Ну и?
Это же не так.
>Нахуй тебе их вообще сравнивать?
Я не тот челик, но вон та же идея решала эту задачу для поиска дубликации кода.
>>8029
Смотря что считать равенством лямбды. Это уже зависит от задачи, которой у тебя нет.
Нахуй тебе искать дубликацию кода? И каким образом лябмды к этому относятся?
> Это же не так.
Смотря что считать равенством лямбды. Это уже зависит от задачи, которой у тебя нет.
> но вон та же идея решала эту задачу для поиска дубликации кода.
Нахуй тебе искать дубликацию кода? И каким образом лябмды к этому относятся?
>>7840
Как потопаешь, так и полопаешь. У тебя всегда есть опция сменить работу, другое дело - будут ли тебе вообще где либо платить столько, сколько ты хочешь. 2 года опыта - ниочем, некоторые сеньки и за 10 лет реальной экспертизы и кгомпетенций за душой не имеют. Так что я б на твоем месте как минимум не корежился в саморефлексии. Устроился - уже хорошо. Многие вон и устроиться не могут...
Как потопаешь, так и полопаешь. У тебя всегда есть опция сменить работу, другое дело - будут ли тебе вообще где либо платить столько, сколько ты хочешь. 2 года опыта - ниочем, некоторые сеньки и за 10 лет реальной экспертизы и кгомпетенций за душой не имеют. Так что я б на твоем месте как минимум не корежился в саморефлексии. Устроился - уже хорошо. Многие вон и устроиться не могут...
>>8166
В смысле вкатуны? А кому ещё работу искать?
В смысле вкатуны? А кому ещё работу искать?
>>7592
Там древняя как сам MySQL так и сервак, который к нему имеет доступ. Ну даже если получится пробить через безопасников что я к этой базе буду подключаться с другой виртуалки, более современной, то всё равно исходная база на 10 летней давности MySQL и обновляться там никто не хочет, слишком трудозатратно. Такие системы наверное обычно живут до конца а потом их выкидывают и делают новые. Так что while(true) sleep(timeout) ...
Там древняя как сам MySQL так и сервак, который к нему имеет доступ. Ну даже если получится пробить через безопасников что я к этой базе буду подключаться с другой виртуалки, более современной, то всё равно исходная база на 10 летней давности MySQL и обновляться там никто не хочет, слишком трудозатратно. Такие системы наверное обычно живут до конца а потом их выкидывают и делают новые. Так что while(true) sleep(timeout) ...
>>8136
Залетный чтоли?
Последние года на весь /pr/ стоит вой вкатунов. Не ебу кто все эти люди, но хз каким глухим и слепым надо быть чтобы эту хуету не замечать. Наверное все это ж-ж-ж - неспроста...
Залетный чтоли?
Последние года на весь /pr/ стоит вой вкатунов. Не ебу кто все эти люди, но хз каким глухим и слепым надо быть чтобы эту хуету не замечать. Наверное все это ж-ж-ж - неспроста...
>>8182
Можно хоть одну ссылку на такой пост в тредах с джавой?
Где чувак ноет, что долго ищет работу и не может найти, и там, не знаю, совета просит по этому поводу какого.
Можно хоть одну ссылку на такой пост в тредах с джавой?
Где чувак ноет, что долго ищет работу и не может найти, и там, не знаю, совета просит по этому поводу какого.
>>8181
Самое рофляное там даже не подключение с другой виртуалки. Чтоб дебезиум работал, надо на БД бинлог включать, и вот здесь то уже и может встать во весь рост бюрократический аппарат, да и вопросики совместимости не исключены.
мимо
Самое рофляное там даже не подключение с другой виртуалки. Чтоб дебезиум работал, надо на БД бинлог включать, и вот здесь то уже и может встать во весь рост бюрократический аппарат, да и вопросики совместимости не исключены.
мимо
>>8184
Ныли в 2022, 2023, мб ещё немного в 2024, сейчас уже нет смысла ныть. Это как ныть что спина болит — все и так знают что у людей хуёвый позвоночник.
Ныли в 2022, 2023, мб ещё немного в 2024, сейчас уже нет смысла ныть. Это как ныть что спина болит — все и так знают что у людей хуёвый позвоночник.
>>8184
Я не могу найти 3 года опыт. Откликнулся на 7 вакансий, 1 отказ, 6 не просмотрели. Одна эйчарка сама меня нашла из сбера, сказала, что в сбере сейчас четырехэтапный собес. 1-ый базаришь с хрю, 2-ой делаешь час какой-то рефакторинг, 3-ий лайвкодинг, 4-ый техническое интервью. Я скипнул после 1-ой ступени, т.к испугался, я слаб в олимпиадном программировании, и что за рефакторинг такой, она объяснить не смогла. Ну моя проблема в том что я не откликаюсь, пока не работаю, думаю что должен изучить webFlux, т.к. это супермодно, пока не знаю зачем он нужен, если есть restTemplate и feign.
Я не могу найти 3 года опыт. Откликнулся на 7 вакансий, 1 отказ, 6 не просмотрели. Одна эйчарка сама меня нашла из сбера, сказала, что в сбере сейчас четырехэтапный собес. 1-ый базаришь с хрю, 2-ой делаешь час какой-то рефакторинг, 3-ий лайвкодинг, 4-ый техническое интервью. Я скипнул после 1-ой ступени, т.к испугался, я слаб в олимпиадном программировании, и что за рефакторинг такой, она объяснить не смогла. Ну моя проблема в том что я не откликаюсь, пока не работаю, думаю что должен изучить webFlux, т.к. это супермодно, пока не знаю зачем он нужен, если есть restTemplate и feign.
>>7840
Чё тебе мешает работая походить по собесам, прося больше? Тем более они все в телемосте сейчас, без камер. И если нарисуется варик, свичнуться.
Чё тебе мешает работая походить по собесам, прося больше? Тем более они все в телемосте сейчас, без камер. И если нарисуется варик, свичнуться.
>>8362
Ну там чел просит поныть, вот я импровизирую. Помогайте мне, давайте думать
Ну там чел просит поныть, вот я импровизирую. Помогайте мне, давайте думать
>>8387
Каких?
Каких?
>>8397
Эти велокурьеры с 200к зп с нами в одном треде? Я тебе секрет открою, но курьеры получают зп не за часы и у них нет оклада, да даже трудового нет.
Эти велокурьеры с 200к зп с нами в одном треде? Я тебе секрет открою, но курьеры получают зп не за часы и у них нет оклада, да даже трудового нет.
>>8397
А почему должен соразмерно или больше?
Хочешь получать больше - пиздуешь крутиться и доказывать что стоишь больше велошкурьера. Пиздуешь торговать собой на рынок труда. Душишся о десятки гейткиперских собесов на сытное место, либо крутишся в потугах релокнуться туда, где лишних денег больше. Либо растешь и берешь на себя больше обязательств и ответственности, становишься незаменимым и торгуешь этой незаменимостью (тогда могут и на 60% поднять). На худой конец, переквалифицируешься в курьеры, если как ты гришь им платят больше. А пока не доказал обратное, не то что для локального кабана - для любого мимокрока-двачера ты никто и звать тебя никак, и денег своих ты не стоишь. такие дела.
А то раскатили саморефлексию блять, что аж FOMO и "от мыслей корежит". Ну сходи пополни собой коммьюнити потешных доходяг с another-it, фанфик напиши там о том, как стыдно быть программистом. Это точно повысит твои акции.
А почему должен соразмерно или больше?
Хочешь получать больше - пиздуешь крутиться и доказывать что стоишь больше велошкурьера. Пиздуешь торговать собой на рынок труда. Душишся о десятки гейткиперских собесов на сытное место, либо крутишся в потугах релокнуться туда, где лишних денег больше. Либо растешь и берешь на себя больше обязательств и ответственности, становишься незаменимым и торгуешь этой незаменимостью (тогда могут и на 60% поднять). На худой конец, переквалифицируешься в курьеры, если как ты гришь им платят больше. А пока не доказал обратное, не то что для локального кабана - для любого мимокрока-двачера ты никто и звать тебя никак, и денег своих ты не стоишь. такие дела.
А то раскатили саморефлексию блять, что аж FOMO и "от мыслей корежит". Ну сходи пополни собой коммьюнити потешных доходяг с another-it, фанфик напиши там о том, как стыдно быть программистом. Это точно повысит твои акции.
>>8463
Как твои успехи в раканьи? Какое впечатление от языка, тулзов и прочего? Расскажи, мне действительно интересно~
Как твои успехи в раканьи? Какое впечатление от языка, тулзов и прочего? Расскажи, мне действительно интересно~
>>8438
Ты из какого города? В ДС 100 т.р. даже на еду не хватит, не говоря уже о том чтобы снять, например, квартиру. Почему кодер должен быть полубомжом каким-то, я из простыни твоей не понял.
Ты из какого города? В ДС 100 т.р. даже на еду не хватит, не говоря уже о том чтобы снять, например, квартиру. Почему кодер должен быть полубомжом каким-то, я из простыни твоей не понял.
>>8536
Да че ты доебался с инфантильным бредом каким то - "должен, должен".
Никто ничего никому не должен. Работаешь - значит всем доволен. Какая кому разница из какого ты города.
Да че ты доебался с инфантильным бредом каким то - "должен, должен".
Никто ничего никому не должен. Работаешь - значит всем доволен. Какая кому разница из какого ты города.
>>8557
Ты должен мне минет! Что б завтра, к восьми, был у меня дома! И не опаздывать! Понял!?
Ты должен мне минет! Что б завтра, к восьми, был у меня дома! И не опаздывать! Понял!?
>>7850
1. Аналитически задача доказательства равенства функций вполне себе решается путем преобразования или нахождения значений при который функции не эквивалентны.
2. В условиях компьютерной программы, все типы так или иначе конечны и можно просто перебрать все значения. И никакой проблемы останова тут нет, есть проблема что надо перебрать слишком много значений. Но множество всех значений функции конечно доказательство этого факта оставим читателям.
>Это в общем случае невозможно из-за проблемы остановки.
1. Аналитически задача доказательства равенства функций вполне себе решается путем преобразования или нахождения значений при который функции не эквивалентны.
2. В условиях компьютерной программы, все типы так или иначе конечны и можно просто перебрать все значения. И никакой проблемы останова тут нет, есть проблема что надо перебрать слишком много значений. Но множество всех значений функции конечно доказательство этого факта оставим читателям.
>>8603
google://idea column selection mode hotkey
google://idea column selection mode hotkey
>>4087 (OP)
Перестали писать рекрутеры. Раньше регулярно получал предложения пройти собес в сбер, озон или яшку. Прилетали приглашения в линкедин и на почту с телегой. Но начиная с января этого года тишина. Почему так?
Перестали писать рекрутеры. Раньше регулярно получал предложения пройти собес в сбер, озон или яшку. Прилетали приглашения в линкедин и на почту с телегой. Но начиная с января этого года тишина. Почему так?
>>8676
Айти обслуживает бизнес. Когда экономика рухнум на айтишниках это сказывается первыми.
Расслабься, через пару месяцев в других отраслях начнется тоже самое. Хорошо когда у соседа корова сдохла!
Айти обслуживает бизнес. Когда экономика рухнум на айтишниках это сказывается первыми.
Расслабься, через пару месяцев в других отраслях начнется тоже самое. Хорошо когда у соседа корова сдохла!
>>8590
У нас машина Тьюринга. Такое решение нерелевантно.
f(x, y) {return x+y;}
g(x, y) {while(true) ; return 0; }
Докажи мне, что они не эквивалентны, не зная, что у них внутри.
>>Это в общем случае невозможно из-за проблемы остановки.
>1. Аналитически задача доказательства равенства функций вполне себе решается путем преобразования или нахождения значений при который функции не эквивалентны.
У нас машина Тьюринга. Такое решение нерелевантно.
>2. В условиях компьютерной программы, все типы так или иначе конечны и можно просто перебрать все значения. И никакой проблемы останова тут нет,
f(x, y) {return x+y;}
g(x, y) {while(true) ; return 0; }
Докажи мне, что они не эквивалентны, не зная, что у них внутри.
28 Кб, 724x332>>9189
На самом деле return 0 не нужен.
Более того индетичные функции, ведут себя по разному, если редуцировать их в разных порядках...
На самом деле return 0 не нужен.
Более того индетичные функции, ведут себя по разному, если редуцировать их в разных порядках...