Здравствуйте, 0xCAFEDEAD, Вы писали:
CAF>Здравствуйте, arth, Вы писали:
CAF>Честно говоря, по американским меркам, ты им посто нахамил. Думаю, что можно списать на разницу культур, учитывая общий уровень англ. — но вообще это просто жесть.
а при чем здесь америка? может они из австралии? а по факту русские пацаны из питера
CAF>Ксати в дискусси на форуме нет смысла особенно препираться, это тебе с работой не поможет. Твоя задача, не нас уюедить, а понять что у тебя не так. Лучше подумай почему люди тебя не понимают.
откуда ты знаешь какая у меня задача? может мне тут пободаться в кайф и работа мне вообще не нужна?
A>>The solution is no concurrency safe — transaction is not atomic A>> me — there is no explicit requirement and actually basic A>>transaction (add) is atomic. There is no race conditions. Atomicity of A>>_transfer_ is required if we don't want to loose data — but here there A>>is no such problem since we don;t store anything between sessions.
CAF>Не поленился — посмотрел, но синхронизации я не нашел. Поясни, как она делается, и это самое атомисити достигается. CAF>Транзакии/аккаунт — классические пример для синхронизации. И да, для сервиса — это и так понятное требование.
ConcurrentHashMap.merge — атомарен. Строго говоря для совершения транзакции должно соблюдаться три условия:
1 атомарное дебетирование источника
2 атомарное кредитование получателя
3 предшествование первого второму
атомарность всей транзакции — необязательна. я могу сначала списать 2 суммы с одного и того же счета а уже потом перевести их на другие. тут гранулярность не на уровне
перевода со счета на счет, а на уровне изменения баланса аккаунта
единственный вопрос тут может быть к #3 из-за возможного reordering'a инструкций и отсутствия явных memory barriers. но я думаю и тут все чисто
и тут уже не один раз мешали все в кучу — атомарность, потокобезопасность, concurrency, синхронизация.
это все разные вещи.
A>>Insufficient testing coverage A>>nothing to say. It's 6hrs test. Not 40hrs CAF>в принципе тут просто более внятно надо ответить было, и все CAF>хотя я бы тесты вместе с интерфесами нахерачил, а потом имплементацию лепил
A>>If we transfer negative amount money, author don’t throw exceptions, it takes abs value of this amount and transfer positive amount of money. A>>transferring negative amount is something which is odd. So it's a A>>convention. It either has to be documented or exception should be A>>thrown. So I partially agree. CAF>ну это вообще саботаж какой-то, кмк
я в ветке уже несколько раз отвечал.
A>>Author don't know how to catch exceptions in junit A>>minor. Nothing to add. CAF>мдааа
я вообще не очень понимаю суть претензий от них. ты вот мне можешь вместо "мдааа" написать в чем косяк?
A>>Procedure of transferring money is not clear and difficult to support A>>no comment. CAF>Сложность — понятие нескольно субъективное, но да. Пишешь не очень понятно местами. Кучка разбрсанных мелких классов,
о ужас, разбросанные по именованным модулям мелкие классы. очень обще, давай конкретику
A>>Poor documentation — there is no specifications of endpoints, how to build a project A>>KL — there is a README. And there is a build.gradle. It's kind of A>>misunderstanding what we expect from 6hrs test.
CAF>Вот кстати, уже более внятное объяснение. К концы начало получаться немного.