Сравнение некорректное на мой взгляд, лучше сравнивать в одинаковом ценовом диапазоне б.у. от майнинга с б.у. от геймеров и одинаковой видеокартой.
В майнинге если видеокарту обслуживать вовремя, не допускать перегрева, то видеокарта будет не хуже б.у. от геймеров.
И у майнеров есть мотивация для сохранения видеокарты, чтобы меньше тратить ресурсов на ремонт и на случай обвала криптовалют чтобы геймерам продать.
В целом честные майнеры, думаю, будут за, если на видеокарте провести нагрузочные тесты перед покупкой. А после тестов можно быть уверенным, что видеокарта прослужит долго.
Получается для такого транзистора нужно будет реализовывать не двоичную логику вычислений, а "адаптивную".
Интересно, как создатели этих транзисторов представляют реализацию "адаптивных" вычислений, сложить 2 числа например. Нейросети не исключение, тоже числами оперируют.
Как я вижу, автор хотел поделиться своим удивлением о новом поколении программистов или даже людей, у которых навык поиска информации использовался чаще, чем навык создания собственных алгоритмов. Так как, скорее всего, для автора написать свою архитектуру привычнее, чем «нагуглить» готовую.
Я бы сказал, это естественное развитие, потому что действительно бОльшую часть задач можно решить поиском информации в гугл.
А если в проекте есть свои архитектурные решения, то и собеседование должно проверять навыки построения архитектуры.
На мой взгляд, не нужно пытаться оправдать своё нежелание (лень и т.п. причины) составить задачи для собеседования, подходящие под проект, и просто спросить: «а почему именно такое решение?» и будет понятно понимает человек архитектуру, которая будет в проекте или нет, тем что появились «гугл-программисты» и виноваты они. Иначе получается перекладывание ответственности — я бы не хотел иметь дело с такими руководителями.
Сегодня «гугл-программисты» завтра «github-программисты», времена и люди меняются, но чтобы найти ответ, который поможет решить проблему, в первую очередь нужно научиться правильно и точно задавать вопросы.
Во-первых: в статье я хотел описать для новичков в vue как создать компонент или для профессионалов, которые хотят посмотреть как работает vue.
Во-вторых: на мой взгляд vue-google-maps избыточен, не всем и не всегда нужен весь функционал api google карт.
Строка выше — это получение div`a карты, у которого id является свойством компонента — name. Передаётся name из index файла при подключении компонента в строке:
<google-map :name="name"></google-map>
Соответственно, меняя параметр name мы можем разместить несколько компонентов карт на 1 странице. А что бы маркеры были разные, массив маркеров нужно вынести в свойства компонента props аналогично name и, аналогично name задать отдельные массивы маркеров. В статье я упомянул про эту возможность.
Согласен со всем выше сказанным. Но! В рамках статьи я хотел описать максимально простой вариант компонента с минимальным количеством кода, что бы было общее понимание концепции. Если интересно — могу улучшить код с точки зрения правильности/стандартов написания и написать статью для динамической карты объектов в которой массив vue будет связан с маркерами карты, при изменении массива — будут сразу меняться маркеры на карте.
Открывал, конечно.
Для написания статьи я использовал сборку vue на основе nuxtjs.org. Подобной ошибки не было. Если возможно — дайте пруф линк на информацию, где описано, что тег script запрещён в шаблонах vue, интересно.
Задача 1, дополнения:
Предложенное решение выше сработает в большинстве случаев, но не сработает если случайно попадётся такая же комбинация как и шаблон.
Что бы решить окончательно и правильно, нужны дополнительные данные, например максимально возможное количество вагонов, иначе условие «Количество вагонов конечно», сводится к условию «Количество вагонов стремится к бесконечности»
Суть решения:
Задаём свой уникальный шаблон переключателей, не похожий на случайный набор, как только он начнёт повторятся — значит идём по кругу и соответственно знаем число переключателей.
Примерное решение:
1) Движемся вперёд по вагону
2) Запоминаем положение переключателей и делаем счётчик
3) Последовательно включаем-> выключаем переключатели
4) Сравниваем запомненные переключатели от первого до последнего запомненного и второго до последнего запомненного
5) Как только сравнение от первого до последнего запомненного и второго до последнего запомненного повторится и при этом число включенных и выключённых переключателей будет равно числу при совпадении от первого до последнего запомненного и второго до последнего запомненного — узнаем число вагонов
Задача 2
1) На краю диска
2) Немного дальше от центра
3) Стакан по центру
Всё зависит от центростремительного ускорения, чем дальше от центра тем оно больше, тем сильнее виляет на стакан и воду.
Задача 3
0.63
Information
Rating
Does not participate
Location
Санкт-Петербург, Санкт-Петербург и область, Россия
Это понятно, но когда я читаю подобный заголовок, я рассчитываю на объективную оценку, а не на личное мнение автора.
Здесь получается кликбейт/самореклама, интереса к курсу меньше из за подобного заголовка, так как есть несоответствие ожиданий и фактов.
Надеюсь, 2 комментария выше - это сарказм
А какое отношение к статье имеет часть заголовка "Выученная беспомощность" ?
Сравнение некорректное на мой взгляд, лучше сравнивать в одинаковом ценовом диапазоне б.у. от майнинга с б.у. от геймеров и одинаковой видеокартой.
В майнинге если видеокарту обслуживать вовремя, не допускать перегрева, то видеокарта будет не хуже б.у. от геймеров.
И у майнеров есть мотивация для сохранения видеокарты, чтобы меньше тратить ресурсов на ремонт и на случай обвала криптовалют чтобы геймерам продать.
В целом честные майнеры, думаю, будут за, если на видеокарте провести нагрузочные тесты перед покупкой. А после тестов можно быть уверенным, что видеокарта прослужит долго.
Имеется ввиду трекеров времени? (Не задач)
Получается для такого транзистора нужно будет реализовывать не двоичную логику вычислений, а "адаптивную".
Интересно, как создатели этих транзисторов представляют реализацию "адаптивных" вычислений, сложить 2 числа например. Нейросети не исключение, тоже числами оперируют.
Я бы сказал, это естественное развитие, потому что действительно бОльшую часть задач можно решить поиском информации в гугл.
А если в проекте есть свои архитектурные решения, то и собеседование должно проверять навыки построения архитектуры.
На мой взгляд, не нужно пытаться оправдать своё нежелание (лень и т.п. причины) составить задачи для собеседования, подходящие под проект, и просто спросить: «а почему именно такое решение?» и будет понятно понимает человек архитектуру, которая будет в проекте или нет, тем что появились «гугл-программисты» и виноваты они. Иначе получается перекладывание ответственности — я бы не хотел иметь дело с такими руководителями.
Сегодня «гугл-программисты» завтра «github-программисты», времена и люди меняются, но чтобы найти ответ, который поможет решить проблему, в первую очередь нужно научиться правильно и точно задавать вопросы.
Во-вторых: на мой взгляд vue-google-maps избыточен, не всем и не всегда нужен весь функционал api google карт.
в es6 не обязателен, при желании можно использовать и синтаксис
Соответственно, меняя параметр name мы можем разместить несколько компонентов карт на 1 странице. А что бы маркеры были разные, массив маркеров нужно вынести в свойства компонента props аналогично name и, аналогично name задать отдельные массивы маркеров. В статье я упомянул про эту возможность.
Для написания статьи я использовал сборку vue на основе nuxtjs.org. Подобной ошибки не было. Если возможно — дайте пруф линк на информацию, где описано, что тег script запрещён в шаблонах vue, интересно.
Предложенное решение выше сработает в большинстве случаев, но не сработает если случайно попадётся такая же комбинация как и шаблон.
Что бы решить окончательно и правильно, нужны дополнительные данные, например максимально возможное количество вагонов, иначе условие «Количество вагонов конечно», сводится к условию «Количество вагонов стремится к бесконечности»
Задаём свой уникальный шаблон переключателей, не похожий на случайный набор, как только он начнёт повторятся — значит идём по кругу и соответственно знаем число переключателей.
Примерное решение:
1) Движемся вперёд по вагону
2) Запоминаем положение переключателей и делаем счётчик
3) Последовательно включаем-> выключаем переключатели
4) Сравниваем запомненные переключатели от первого до последнего запомненного и второго до последнего запомненного
5) Как только сравнение от первого до последнего запомненного и второго до последнего запомненного повторится и при этом число включенных и выключённых переключателей будет равно числу при совпадении от первого до последнего запомненного и второго до последнего запомненного — узнаем число вагонов
2) Немного дальше от центра
3) Стакан по центру
Всё зависит от центростремительного ускорения, чем дальше от центра тем оно больше, тем сильнее виляет на стакан и воду.