Сообщение Re[3]: И вот feedback от них и мои им ответы от 09.03.2019 2:24
Изменено 09.03.2019 2:33 arth
Re[3]: И вот feedback от них и мои им ответы
Здравствуйте, 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 предшествование первого второму
атомарность всей транзакции — необязательна
единственный вопрос тут может быть к #3 из-за возможного reordering'a инструкций и отсутствия явных memory barriers. но я думаю и тут все чисто
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>Вот кстати, уже более внятное объяснение. К концы начало получаться немного.
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 предшествование первого второму
атомарность всей транзакции — необязательна
единственный вопрос тут может быть к #3 из-за возможного reordering'a инструкций и отсутствия явных memory barriers. но я думаю и тут все чисто
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>Вот кстати, уже более внятное объяснение. К концы начало получаться немного.
Re[3]: И вот feedback от них и мои им ответы
Здравствуйте, 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>Вот кстати, уже более внятное объяснение. К концы начало получаться немного.
ну мне не 15 лет чтобы хотеть всем нравиться
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>Вот кстати, уже более внятное объяснение. К концы начало получаться немного.
ну мне не 15 лет чтобы хотеть всем нравиться