В задании вообще ничего не сказано о том, что возвращаемый результат функции должен быть элементом массива. Кое-как об этом можно догадаться по тестовым примерам, но, мягко говоря, с трудом.
И, например, совершенно не очевидно что f(a,2)=-1 - на первый взгляд f(a,2)=2 вполне валидно. Из условия задачи вообще не следует, что х за пределами массива является ошибкой.
Если речь именно о хулиганском срыве урока - это можно сделать и без смартфона, не вижу как особенно смартфон помогает кидаться бумажками в учителя или хамить.
А если 3-5 человек просто раздолбаи и отвлекаются от урока на игрушки в телефоне - ну пусть сядут на заднюю парту и играют себе тихо, мешать остальным они не будут.
В критичном случае деточка может получить люлей и оставить смартфон дома (для срочной связи можно выдать старую нокию). Именно этот вопрос как раз легко решается.
Это отличная идея с точки зрения технической оптимизации, но она обладает фундаментальным недостатком, а именно: если завтра критерий лояльности изменится с "посетил 2 страницы" на "посетил 3 страницы", то вам придется переписывать примерно все.
То есть подобную оптимизацию можно проводить, только трижды согласовав проблему с бизнесом: а нам точно-точно всегда-всегда будет достаточно двух страниц как критерия лояльности? Из моего опыта, даже если менеджер отвечает "точно да" на этот вопрос, верить ему не стоит, т.к. он банально не понимает жизни.
Совершенно верно. Задача "написать так чтобы было понятно" - вообще творческая, сложная. И, кстати, "понятно" отнюдь не означает "коротко".
В программировании этот вопрос отчасти решается введением огромного списка "терминов и определений". Это позволяет сократить каждый конкретный "пункт договора" до некоторой весьма удобоваримой длины, т.к. вся громоздкость уходит внутрь терминов. Однако, мгновенно встает проблема, что большинство "терминов и определений" оказываются запредельно сложны для понимания неподготовленным человеком.
Это как комментарии в коде. На первый взгляд вроде хорошо и полезно, но что делать, когда комментарий (по недосмотру али умыслу) начинает противоречить коду?
Надо код рефакторить, чтобы его можно было понятно читать, а не комментариями обкладываться.
Ну, я например, начал работу программистом C# в декабре 2010-го, в августе 2011-го пришел полным нулем в Android, в мае 2013-го уже работал по факту на сеньорской позиции (то есть полностью вел проект с технической стороны, хотя на тот момент еще не называл себя сеньором из скромности).
Надо сказать, что мне несколько повезло со специализацией - Android тогда только-только начал развиваться, и уже через полгода я был дефакто старшим разработчиком в компании и консультировал нанимаемых новеньких - не потому, что я сильно дофига знал по Android, но потому что я знал больше чем все остальные сотрудники в компании.
Так что я соглашусь с тем что лет 10 назад вкатываться в айти было попроще...
С этим тестом как раз все понятно, там чтения и потенциальная возможность/целесообразность их переупорядочивания вполне очевидна.
С п.2 все не так очевидно. Хотя, я, кажется, начинаю понимать, что вы имеете в виду.
Теоретически, можно предположить, что скомпилированный код
а) сначала прочитает значение переменной instance для использования в строке 90 return instance; В этот момент может прочитаться null
б) позднее еще раз прочитает значение переменной instance для использования в строке 87 if (instance == null), и в этот момент прочитается не-null
Так получается?
Теоретически, вроде бы, действительно я не вижу противоречия упомянутым правилам happens-before при таком раскладе. Но выглядит как-то совсем бредово...
Подумал третий раз и увидел, что в тех случаях, когда мы возвращаем объект mock, мы не делаем проверок на его содержимое и всегда возвращаем -1, так что моя гипотеза в п.1 скорее всего неактуальна (хотя стоило бы проверить на всякий случай)
Подумал еще раз и понял, что ситуацию с перестановкой местами вызова конструктора и присваивания ссылки мы также можем видеть и для instance = new Foo(); в строке 83. В этом случае строка 90 return instance; тоже может возвращать недозаполненный объект и триггерить outcome 0.
В п.2 чтения как раз таки связаны, и они не могут быть поменяны местами, т.к. это ломает консистентность в пределах одного потока. Точнее, сами чтения-то не связаны, а вот чтение + последующая return - очень даже связаны. Если в строке 87 instance == null выполняется, инструкция return instance; не может быть выполнена, ибо они в одном потоке.
А вот в процедуре создания объекта mock как раз таки возможна та самая перестановка, о которой я говорю в своем пункте 1, а вы - в своем последнем абзаце, когда вызов конструктора и присваивание ссылки на созданный объект меняются местами. В этом случае (очевидно предположить, что инициализация статической переменной mock случается в каком-то третьем потоке [утверждение требует проверки - ред.]) в строке 88 может быть возвращен "недозаполненный" объект mock, который триггерит @Outcome(id = "0", expect = Expect.ACCEPTABLE_INTERESTING, desc = "Object's data is null")
Так. Тут происходит что-то очень интересное, но не совсем очевидное.
1) Я так понимаю, что в некоторых случаях в ссылку Foo.mock оказывается записан валидный объект ДО того, как констуктор этого Foo.mock отработает. Ноооо... в каком треде происходит выполнение инструкции static final Foo mock = new Foo();и почему?
2) У вас в строке 90 приписан комментарий return instance; // can return null Это сбивает с толку - действительно ли в этой строке может вернуться null? Это же нарушает reordering в пределах одного потока. И в ваших тестах нет ни одного подобного случая.
Да все еще проще. Без правила "тронул - ходи" (там есть еще вторая часть - "отпустил фигуру - ход сделан") можно переставить местами полдоски, мотивируя это тем, что "мне так удобнее думать". Потом замучаешься вспоминать и доказывать, как фигуры стояли изначально.
Ну, во-первых, паспорт есть у всех, а аккаунт на госуслугах - нет. И, да, я не вижу причин, по которым наличие аккаунта на госуслугах должно быть обязательно для "нормального человека".
Во-вторых, очевидно, что у государства появится глобальный реестр доменов, где на каждого Васю Пупкина будет виден список доменов, которые на него зарегистрированы. Очень удобно будет в случае признания Васи экстремистом заблокировать все его сайты. Раньше такой реестр был только у каждого регистратора в отдельности.
Или нервов, передающих сигнал от рецептора в мозг. Или стуктур в мозге, которые этот сигнал от нервов принимают.
Да, теоретически. Но в контексте респираторного вируса гораздо более вероятно предполагать, что этот вирус что-то там поломает в носу (где вирус обитает в больших количествах), чем ожидать, что вирус магическим образом проникает в мозг и устанавливает там вредоносное китайское ПО поражает нейроны и прочее, что там в мозгу находится.
Последнее предположение тем более невероятно, если учесть, что потеря запаха-вкуса - симптом сравнительно распространенный, а вот другие нарушения мозга (потеря зрения, осязания, слуха, амнезия, эпилепсия, что там еще бывает?) наблюдаются крайне редко. Вряд ли вирус настолько избирателен, что поражает именно те участки мозга, что отвечают только за обоняние.
Пара газетныхвырезок на эту тему (не ланцет, зато доступно для понимания).
Разворачивая вашу мысль для тех, кто не понял:
В задании вообще ничего не сказано о том, что возвращаемый результат функции должен быть элементом массива. Кое-как об этом можно догадаться по тестовым примерам, но, мягко говоря, с трудом.
И, например, совершенно не очевидно что f(a,2)=-1 - на первый взгляд f(a,2)=2 вполне валидно. Из условия задачи вообще не следует, что х за пределами массива является ошибкой.
Если речь именно о хулиганском срыве урока - это можно сделать и без смартфона, не вижу как особенно смартфон помогает кидаться бумажками в учителя или хамить.
А если 3-5 человек просто раздолбаи и отвлекаются от урока на игрушки в телефоне - ну пусть сядут на заднюю парту и играют себе тихо, мешать остальным они не будут.
В критичном случае деточка может получить люлей и оставить смартфон дома (для срочной связи можно выдать старую нокию). Именно этот вопрос как раз легко решается.
Если 83% родителей против смартфонов в школах, что же они не запрещают своим детям использовать смартфоны на уроках?
Добавлю ссылку на свой же коммент на эту тему, но в другой ветке
Это отличная идея с точки зрения технической оптимизации, но она обладает фундаментальным недостатком, а именно: если завтра критерий лояльности изменится с "посетил 2 страницы" на "посетил 3 страницы", то вам придется переписывать примерно все.
То есть подобную оптимизацию можно проводить, только трижды согласовав проблему с бизнесом: а нам точно-точно всегда-всегда будет достаточно двух страниц как критерия лояльности? Из моего опыта, даже если менеджер отвечает "точно да" на этот вопрос, верить ему не стоит, т.к. он банально не понимает жизни.
Совершенно верно. Задача "написать так чтобы было понятно" - вообще творческая, сложная. И, кстати, "понятно" отнюдь не означает "коротко".
В программировании этот вопрос отчасти решается введением огромного списка "терминов и определений". Это позволяет сократить каждый конкретный "пункт договора" до некоторой весьма удобоваримой длины, т.к. вся громоздкость уходит внутрь терминов. Однако, мгновенно встает проблема, что большинство "терминов и определений" оказываются запредельно сложны для понимания неподготовленным человеком.
Это как комментарии в коде. На первый взгляд вроде хорошо и полезно, но что делать, когда комментарий (по недосмотру али умыслу) начинает противоречить коду?
Надо код рефакторить, чтобы его можно было понятно читать, а не комментариями обкладываться.
Ну, я например, начал работу программистом C# в декабре 2010-го, в августе 2011-го пришел полным нулем в Android, в мае 2013-го уже работал по факту на сеньорской позиции (то есть полностью вел проект с технической стороны, хотя на тот момент еще не называл себя сеньором из скромности).
Надо сказать, что мне несколько повезло со специализацией - Android тогда только-только начал развиваться, и уже через полгода я был дефакто старшим разработчиком в компании и консультировал нанимаемых новеньких - не потому, что я сильно дофига знал по Android, но потому что я знал больше чем все остальные сотрудники в компании.
Так что я соглашусь с тем что лет 10 назад вкатываться в айти было попроще...
И все же сложнее. Что проще - перефоткать на телефон 20 страниц текста или переслать один файл весом в пару мегабайт?
С этим тестом как раз все понятно, там чтения и потенциальная возможность/целесообразность их переупорядочивания вполне очевидна.
С п.2 все не так очевидно. Хотя, я, кажется, начинаю понимать, что вы имеете в виду.
Теоретически, можно предположить, что скомпилированный код
а) сначала прочитает значение переменной instance для использования в строке 90
return instance;В этот момент может прочитаться nullб) позднее еще раз прочитает значение переменной instance для использования в строке 87
if (instance == null), и в этот момент прочитается не-nullТак получается?
Теоретически, вроде бы, действительно я не вижу противоречия упомянутым правилам happens-before при таком раскладе. Но выглядит как-то совсем бредово...
Подумал третий раз и увидел, что в тех случаях, когда мы возвращаем объект mock, мы не делаем проверок на его содержимое и всегда возвращаем -1, так что моя гипотеза в п.1 скорее всего неактуальна (хотя стоило бы проверить на всякий случай)
Подумал еще раз и понял, что ситуацию с перестановкой местами вызова конструктора и присваивания ссылки мы также можем видеть и для
instance = new Foo();в строке 83. В этом случае строка 90return instance;тоже может возвращать недозаполненный объект и триггерить outcome 0.Но возвращать null строка 90 все равно не может
Эмммм, по-моему вы заблуждаетесь.
В п.2 чтения как раз таки связаны, и они не могут быть поменяны местами, т.к. это ломает консистентность в пределах одного потока. Точнее, сами чтения-то не связаны, а вот чтение + последующая return - очень даже связаны. Если в строке 87
instance == nullвыполняется, инструкцияreturn instance;не может быть выполнена, ибо они в одном потоке.А вот в процедуре создания объекта mock как раз таки возможна та самая перестановка, о которой я говорю в своем пункте 1, а вы - в своем последнем абзаце, когда вызов конструктора и присваивание ссылки на созданный объект меняются местами. В этом случае (очевидно предположить, что инициализация статической переменной mock случается в каком-то третьем потоке [утверждение требует проверки - ред.]) в строке 88 может быть возвращен "недозаполненный" объект mock, который триггерит
@Outcome(id = "0", expect = Expect.ACCEPTABLE_INTERESTING, desc = "Object's data is null")Так. Тут происходит что-то очень интересное, но не совсем очевидное.
1) Я так понимаю, что в некоторых случаях в ссылку Foo.mock оказывается записан валидный объект ДО того, как констуктор этого Foo.mock отработает. Ноооо... в каком треде происходит выполнение инструкции
static final Foo mock = new Foo();и почему?2) У вас в строке 90 приписан комментарий
return instance; // can return nullЭто сбивает с толку - действительно ли в этой строке может вернуться null? Это же нарушает reordering в пределах одного потока. И в ваших тестах нет ни одного подобного случая.Да все еще проще. Без правила "тронул - ходи" (там есть еще вторая часть - "отпустил фигуру - ход сделан") можно переставить местами полдоски, мотивируя это тем, что "мне так удобнее думать". Потом замучаешься вспоминать и доказывать, как фигуры стояли изначально.
А можно ссылочку на это самое федеральное законодательство? Какая именно статья устанавливает этот запрет?
Провайдеров электронной почты - мильен, на любой вкус и цвет. Если ни один не нравится, можно сделать вообще свой собственный.
Если мне не нравится провайдер Госуслуг, я могу сделать себе аналогичный аккаунт где-то на другом сервисе?
Ну, во-первых, паспорт есть у всех, а аккаунт на госуслугах - нет. И, да, я не вижу причин, по которым наличие аккаунта на госуслугах должно быть обязательно для "нормального человека".
Во-вторых, очевидно, что у государства появится глобальный реестр доменов, где на каждого Васю Пупкина будет виден список доменов, которые на него зарегистрированы. Очень удобно будет в случае признания Васи экстремистом заблокировать все его сайты. Раньше такой реестр был только у каждого регистратора в отдельности.
Да, теоретически. Но в контексте респираторного вируса гораздо более вероятно предполагать, что этот вирус что-то там поломает в носу (где вирус обитает в больших количествах), чем ожидать, что вирус магическим образом проникает в мозг и
устанавливает там вредоносное китайское ПОпоражает нейроны и прочее, что там в мозгу находится.Последнее предположение тем более невероятно, если учесть, что потеря запаха-вкуса - симптом сравнительно распространенный, а вот другие нарушения мозга (потеря зрения, осязания, слуха, амнезия, эпилепсия, что там еще бывает?) наблюдаются крайне редко. Вряд ли вирус настолько избирателен, что поражает именно те участки мозга, что отвечают только за обоняние.
Пара газетных вырезок на эту тему (не ланцет, зато доступно для понимания).