Сама предпосылка о том, что если что-то недоказуемо и не проверяемо, это бесполезно, на мой взгляд, не верна. Ирония в том, что те инструменты, которыми вы пытаетесь унижать философию, даны вам ею же. Именно философия дала нам определение науки, критерии научности и вот это вот все. Нет смысла упрекать философию в недоказуемости, потому что она по определению занимается вопросами, которые не могут изучаться научным методом.
Для т-стопа нужно сначала развернуться спиной вперед
Вы путаете T-stop и Power-slide. T-stop - это когды вы едете прямо на одной ноге, а вторую волочите сзади перпендикулярно движению. Этот способ, наверное, самый простой для выполнения на узких участках (возможно штатник проще, но я не пробовал)
колеса оквадрачиваются за один спуск с хорошей горки и стоят 4-5 тр.
Был период, когда я пользовался роликами как основным средством передвижения, ездил на них на работу и по всем делам. В таком режиме использования в течение 2 лет я так и не стер родные колеса роликов (ролики Seba FR-2). Потом я стал кататься сильно реже, но вот спустя лет 8 эти колеса все еще пригодны к использованию, хотя и уменьшились миллиметров на 8-10 в диаметре
к примеру, образованный индус знает английский так, что средний выпускник российского ВУЗа зеленеет от зависти.
Это не вполне корректный пример. Во-первых английский там является одним из двух государственных языков. Во-вторых там он действительно ощущается нужным. В России я впервые встретил не-русскоговорящего иностранца лет в 19 в университете. В Индии английский язык нужен очень часто. Я был в Бангалоре в офисе одной IT компании и там абсолютно все говорили между собой по-английски. Когда я спросил, почему так, мне ответили, что все они из разных регионов и говорят на разных диалектах. Так и получается, что если ты просто приехал в соседний регион тебе приходится говорить либо на английском, либо на хинди.
Это правда. Но с другой стороны, если эффективность какого-то подхода не доказана это еще не значит, что он не эффективен. Поэтому отказываться от какого-то подхода только потому, что его эффективность не доказана, потенциально может быть ошибкой. С другой стороны если доказана неэффективность метода - то лучше, пожалуй, от него отказаться
если мы знаем, что мир материален и основой взаимодействия является вещество, то отсутствие действующего вещества в лекарстве есть гарантия его бесполезности.
А как же эффект плацебо? Я ничего не понимаю в медецине, но, насколько мне известно, эффект плацебо доказан. Это тоже можно свести к тому, что организм, вероятно, сам генерирует действующее вещество, но так же можно объяснить и гомеопатию.
Думаю стоит уточнить, что я лично не являюсь сторонником гомеопатии или каких-либо нетрадиционных подходов, но тезис из статьи мне показался разумным и я решил поддержать его.
Думаю, у фейсбука есть способы определить, что вы это вы. А информации из инстаграмма можно получить очень много: фото, геометки с фото, сеть ваших социальных контактов, сообщения, история ваших посещений других страниц. А учитывая то, как активно сейчас продвигаются бизнес страницы в инстаграмм, то история ваших посещений это просто кладезь информации для таргетированной рекламы. А можно еще анализировать сами фотографии и понимать где вы находитесь и чем занимаетесь
Я думаю тут все просто, залез внутрь реализации — сам себе злобный буратино. Каждый кто это делает должен это понимать. И даже если он этого не понимает — это не проблема автора библиотеки.
Тут есть хинт — но надо понимать, что он нужен, когда вы хотите, чтобы считалось быстро, и не собираетесь гарантировать безопасность — можно формулы, введенные юзером, воткнуть в c++ файлик, его откомпилировать и dlopen-ом подгрузить :)
Сначала одни решат, что локально испольнение случайного кода не так уж и страшно. Потом кто-то другой решит сделать веб сервис на основе этого приложения. И вот вам уже готовая RCE :)
Идея в том что если персонажи полностью независимы то нам не нужен меч-у нас есть просто другой герой.
В этом случае я соглашусь, что наследование подойдет. И здесь это следует из самой постановки задачи. В статье приведен пример персонажа, у которого меч изначально не вынесен в отдельную сущность. Меч выносится в отдельную сущность только после того, как возникла необходимость дать ему дубину. Если же задача не «дать этому персонажу дубину», а «сделать другой вид персонажа», то наследование подходит лучше. И этот случай не исключает DI, у этих отдельных персонажей все еще потенциально может быть больше одного оружия, которые все еще лучше реализовать через DI (в случае необходимости).
так прыжки реализованы в зависимости от веса, напрямую у героя нету этого свойства.
Если хватает времени — то надо добавить такое свойство, раз появилась такая необходимость. Если это требует больших изменений, а времени нет — то вес персонажа можно контролировать в самом методе получения веса, для этого не надо волшебных невесомых шапок.
Идея что DI -не серебряная пуля, а ifы и наследование никак не однозначное зло, абстракции нужно выбирать с умом. И это правда сложная задача! Обычно для правильного создания всех абстракций нужно понимание бизнес логики и чего хочет бизнес в итоге.
Это бесспорно. В статье и не говорится, что наследование или условные операторы — это однозначное зло. Там идет речь о том, что они не подходят для поставленной задачи. А вот понять, что за задача перед тобой стоит и что лучше подходит для ее решения — это, как вы и сказали, очень непросто и приходит с опытом.
В описании второго варианта, на мой взгляд, есть пара изъянов:
1 (субъективный). Вы так говорите, как будто создание отдельных реализаций каждого из интерфейсов сильно дольше чем if-ы/наследование. Но с учетом мощи современных IDE, я не думаю, что разница значительна.
2. Если вору надо прыгать выше — надо реализовывать эту особенность в воре, зачем трогать одежду? Решение с невесомой шапкой изначально было обречено на провал
В этом и соль! В сях я примерно представляю как это все хранится в памяти и как примерно обрабатывается, а вот в PHP или JS не имею такого понимания. Жаль, что статья не об этом. Точнее об этом, но не так глубоко, как я ожидал
А что если в остальном мире прознали, что в России эти частоты используются военными и космонавтами, и именно поэтому решили задействовать их? **поправляет шапочку из фольги**
Примечательно, что информация под спойлером выясняется во 2 главе книги (в самом начале), в то время как не-спрятанная информация про землю всплывает только в 28 главе. Не то вы спрятали)
Это страдательный залог. У нас в этой случае добавляется -ся/-сь, а в английском нет специальной слово-формы для этого. Вот здесь я написал об этом чуть подробнее
Я не лингвист, но, насколько я знаю, это не верно. Пассивный залог в английском языке — это пассивный залог в русском. Страдательный залог это несколько иное. Приведу пример (упоминалось ниже):
«A product will release in 2019» — «Продукт выпустится в 2019»
«A product will be released in 2019» — «Продукт будет выпущен в 2019»
Как вы можете заметить, страдательного залога в английском нет (у нас добавляться -ся/-сь). Понять, что используется страдательный залог можно по отсутствию объекта в предложении после глагола.
Почему-то после прочтения захотелось попробовать реализовать нечто похожее, но на генетических алгоритмах. Но что-то мне подсказывает, что через минут 15 это желание пройдет :)
Если в команде один разработчик и кода не слишком много — то пользы от юнит тестов мало. А вот если много людей и большой проект — они необходимы. Я рассматриваю юнит тесты как живую документацию. На мой взгляд они помогают решить следующие проблемы:
— Если ты изменил поведение — они напомнят тебе, что раньше было иначе и надо бы изменить юнит тесты (т.е. документацию)
— Новый человек может неверно понять принципы работы модуля. Когда он сделает правку, которая противоречит дизайну — юнит тесты скорее всего об этом оповестят.
— В юнит тестах можно подсмотреть примеры вызова методов и того, что они возвращают.
— Ну и наконец это отличный способ отладки модуля в процессе разработки, чтобы не стартовать все приложение.
Of course, he would never agree to correct anything, so I would then have to take the report to the company directors. They were statistically illiterate, too, but, being the directors, they could drag things out even more.
Думаю, что не отчеты были неграмотны, а директоры.
Сама предпосылка о том, что если что-то недоказуемо и не проверяемо, это бесполезно, на мой взгляд, не верна. Ирония в том, что те инструменты, которыми вы пытаетесь унижать философию, даны вам ею же. Именно философия дала нам определение науки, критерии научности и вот это вот все. Нет смысла упрекать философию в недоказуемости, потому что она по определению занимается вопросами, которые не могут изучаться научным методом.
Вы путаете T-stop и Power-slide. T-stop - это когды вы едете прямо на одной ноге, а вторую волочите сзади перпендикулярно движению. Этот способ, наверное, самый простой для выполнения на узких участках (возможно штатник проще, но я не пробовал)
Был период, когда я пользовался роликами как основным средством передвижения, ездил на них на работу и по всем делам. В таком режиме использования в течение 2 лет я так и не стер родные колеса роликов (ролики Seba FR-2). Потом я стал кататься сильно реже, но вот спустя лет 8 эти колеса все еще пригодны к использованию, хотя и уменьшились миллиметров на 8-10 в диаметре
Это не вполне корректный пример. Во-первых английский там является одним из двух государственных языков. Во-вторых там он действительно ощущается нужным. В России я впервые встретил не-русскоговорящего иностранца лет в 19 в университете. В Индии английский язык нужен очень часто. Я был в Бангалоре в офисе одной IT компании и там абсолютно все говорили между собой по-английски. Когда я спросил, почему так, мне ответили, что все они из разных регионов и говорят на разных диалектах. Так и получается, что если ты просто приехал в соседний регион тебе приходится говорить либо на английском, либо на хинди.
Это правда. Но с другой стороны, если эффективность какого-то подхода не доказана это еще не значит, что он не эффективен. Поэтому отказываться от какого-то подхода только потому, что его эффективность не доказана, потенциально может быть ошибкой. С другой стороны если доказана неэффективность метода - то лучше, пожалуй, от него отказаться
А как же эффект плацебо? Я ничего не понимаю в медецине, но, насколько мне известно, эффект плацебо доказан. Это тоже можно свести к тому, что организм, вероятно, сам генерирует действующее вещество, но так же можно объяснить и гомеопатию.
Думаю стоит уточнить, что я лично не являюсь сторонником гомеопатии или каких-либо нетрадиционных подходов, но тезис из статьи мне показался разумным и я решил поддержать его.
Так надо просто дождаться пока большинство людей из этих 60% переболеет :)
Сначала одни решат, что локально испольнение случайного кода не так уж и страшно. Потом кто-то другой решит сделать веб сервис на основе этого приложения. И вот вам уже готовая RCE :)
На этот вопрос отвечает очень бородатая заметка от неизвестного
мнеавтора. Если кто-то с ней не знаком, ознакомиться обязательно (тык).В этом случае я соглашусь, что наследование подойдет. И здесь это следует из самой постановки задачи. В статье приведен пример персонажа, у которого меч изначально не вынесен в отдельную сущность. Меч выносится в отдельную сущность только после того, как возникла необходимость дать ему дубину. Если же задача не «дать этому персонажу дубину», а «сделать другой вид персонажа», то наследование подходит лучше. И этот случай не исключает DI, у этих отдельных персонажей все еще потенциально может быть больше одного оружия, которые все еще лучше реализовать через DI (в случае необходимости).
Если хватает времени — то надо добавить такое свойство, раз появилась такая необходимость. Если это требует больших изменений, а времени нет — то вес персонажа можно контролировать в самом методе получения веса, для этого не надо волшебных невесомых шапок.
Это бесспорно. В статье и не говорится, что наследование или условные операторы — это однозначное зло. Там идет речь о том, что они не подходят для поставленной задачи. А вот понять, что за задача перед тобой стоит и что лучше подходит для ее решения — это, как вы и сказали, очень непросто и приходит с опытом.
1 (субъективный). Вы так говорите, как будто создание отдельных реализаций каждого из интерфейсов сильно дольше чем if-ы/наследование. Но с учетом мощи современных IDE, я не думаю, что разница значительна.
2. Если вору надо прыгать выше — надо реализовывать эту особенность в воре, зачем трогать одежду? Решение с невесомой шапкой изначально было обречено на провал
«A product will release in 2019» — «Продукт выпустится в 2019»
«A product will be released in 2019» — «Продукт будет выпущен в 2019»
Как вы можете заметить, страдательного залога в английском нет (у нас добавляться -ся/-сь). Понять, что используется страдательный залог можно по отсутствию объекта в предложении после глагола.
— Если ты изменил поведение — они напомнят тебе, что раньше было иначе и надо бы изменить юнит тесты (т.е. документацию)
— Новый человек может неверно понять принципы работы модуля. Когда он сделает правку, которая противоречит дизайну — юнит тесты скорее всего об этом оповестят.
— В юнит тестах можно подсмотреть примеры вызова методов и того, что они возвращают.
— Ну и наконец это отличный способ отладки модуля в процессе разработки, чтобы не стартовать все приложение.
Думаю, что не отчеты были неграмотны, а директоры.