Почему вундеркиндов? Он начал программировать в 13 лет, вполне уже осознанный возраст. Естественно в 26 ( через 13 лет! ), список достижений может быть существенным.
Даже если взять его универ, уже 5 лет опыта/обучения/разработки, что не так уж и мало.
Вопрос скорее в увлеченности, трудолюбии и терпении, а тут не нужно быть вундеркиндом
Вот не совсем понятно, как это компонент использовать только в дев режиме. В проде конечному клиенту этот компонент не нужен. Хотелось бы в идеале иметь сборку с Profiler-ом и без, так сказать перфтесты. Но в текущей реализацию не понятно, как это сделать
Тут вопрос насколько сложное приложение, если это простой ЮИ — то обычно, это все не нужно, create-react-app прекрасно будет работать, а если много бизнес логики на клиенте — это уже совсем другой опыт и тут специализированные утилиты как раз очень помогают.
Но ведь hq тоже не подойдет для больших проектов
It might help to serve small projects with very little dependencies
Чет я не совсем понял хейта по поводу бандлов. Какие-то надуманные проблемы с соурсмапами. Тот же вебпак эмулирует файловую структуру проекта через соурсмапы, так что к каждому отдельному модулю будет доступ ( даже к node_modules ) + именно для разработки есть dev-server. Ну и конфигурация: по сути своей один раз настроил и используй во всех проектах. Куча же всяких boilerplate-ов есть.
А тут: для разработки один инструмент, для прода другой. Давайте еще для тестирования придумаем что-нибудь
Думаю, в данном случае, вместо мешанины из нескольких циклов можно было бы простенький конечный автомат использовать. Реализовать его как какой-нибудь класс Dialog. Тогда мы бы обошлись одним циклом. Просто бы принимали event, передавали бы его инстансу класса ( для каждого пользователя свой ), и инстанс бы сам решал, что именно нужно сделать с event.
Забавно, что сам вчера начал писать бота, который выкладывает в паблик картинки, которые прислали в конфе. Правда столкнулся с проблемой, что во-первых atttachments, который приходит при событии longpoll имеет не очень удобный формат:
Второе, это то что картинки, которые скинули в конфу невсегда доступны по прямой ссылке, что затрудняет их скачивание и публикацию ( если вообще не блокирует эту возможность )
Пишут, что классы «сложны для понимания», но при этом добавляют ещё одну сущность. Не думаю, что эти прям таки хороший подход. Некоторые примеры, вообще не очевидными кажутся ( например, возвращаемая функция в useEffect )
Я думал холивары про то, можно ли в обработчики компонентов стрелочные функции передавать закончился еще эдак в году 2016ом
if (!Object.prototype.hasOwnProperty.call(this.clickHandlers, key)) {
this.clickHandlers[key] = () => alert(key);
}
Не получится так, что мы будем копить ненужные обработчики событий, которые не удаляются, в случае если список динамический и часто меняется ( корзина товаров, например ).
Легче тогда кнопке передать этот самый key и потом по нему найти. Обработчик один, то что есть поиск, так он в любом случае будет, если мы работаем только с ключом.
Может главная проблема в этом: «Основная наша задача – делать максимальное количество экспериментов в единицу времени и выдавать продуктовые фичи с максимально возможной скоростью.»
Ставить такие условия — заведомо готовить команду к производственному аду и придумыванием всяких правил. Причём, некоторый процент из списка, укладывается и в обычный темп разработки ( ревью кода, отношения внутри команды )
Я так понимаю, что отсутствие чата намекает на то, что играть нужно будет все равно локально? Просто с запущенным сервером. Иначе это просто "угадай и ткни"
Как то скептически отношусь ко всяким «компилируемым в JS» языкам. Мало того, что повышает порог вхождения, так ещё и приносит новые проблемы, в данном случае «биндинги не для новичков», зачем? Если есть immutable.js, где нет таких проблем
Ну, в реальной жизни так же. Вы знаете, что 3 кнопка отдает еду. И вдруг она перестала работать, вам придется снова перенажимать все кнопки, что бы понять, где теперь новая кнопка, дающая еду.
Если увеличить learningRate до 1, то нейросеть будет запоминать это с первой попытки.
Нажимали 3 кнопку >
Получала еду >
Кнопку поменяли >
Перенажимали все кнопки, пока не нашли новую >
Нажимаем теперь ее
Почему вундеркиндов? Он начал программировать в 13 лет, вполне уже осознанный возраст. Естественно в 26 ( через 13 лет! ), список достижений может быть существенным.
Даже если взять его универ, уже 5 лет опыта/обучения/разработки, что не так уж и мало.
Вопрос скорее в увлеченности, трудолюбии и терпении, а тут не нужно быть вундеркиндом
Вот не совсем понятно, как это компонент использовать только в дев режиме. В проде конечному клиенту этот компонент не нужен. Хотелось бы в идеале иметь сборку с
Profiler-оми без, так сказать перфтесты. Но в текущей реализацию не понятно, как это сделатьЕсли используете какой-нибудь
redux, значит уже использовали с помощьconnectВ данном случае, наверное, красивее писать так
Но ведь
hqтоже не подойдет для больших проектовЧет я не совсем понял хейта по поводу бандлов. Какие-то надуманные проблемы с соурсмапами. Тот же вебпак эмулирует файловую структуру проекта через соурсмапы, так что к каждому отдельному модулю будет доступ ( даже к
node_modules) + именно для разработки естьdev-server. Ну и конфигурация: по сути своей один раз настроил и используй во всех проектах. Куча же всякихboilerplate-овесть.А тут: для разработки один инструмент, для прода другой. Давайте еще для тестирования придумаем что-нибудь
Думаю, в данном случае, вместо мешанины из нескольких циклов можно было бы простенький конечный автомат использовать. Реализовать его как какой-нибудь класс
Dialog. Тогда мы бы обошлись одним циклом. Просто бы принималиevent, передавали бы его инстансу класса ( для каждого пользователя свой ), и инстанс бы сам решал, что именно нужно сделать сevent.Идея интересная, просто казалось, что
longpollбудет достаточно, для того, что бы получить всю нужную инфу.Забавно, что сам вчера начал писать бота, который выкладывает в паблик картинки, которые прислали в конфе. Правда столкнулся с проблемой, что во-первых
atttachments, который приходит при событииlongpollимеет не очень удобный формат:Второе, это то что картинки, которые скинули в конфу невсегда доступны по прямой ссылке, что затрудняет их скачивание и публикацию ( если вообще не блокирует эту возможность )
Не обязательно, достаточно
Buttonсделать универсальнойТаким образом можно вообще все что угодно передавать в
Button( но лучше если это будут простые данные, типоid/key/name)Я думал холивары про то, можно ли в обработчики компонентов стрелочные функции передавать закончился еще эдак в году 2016ом
Не получится так, что мы будем копить ненужные обработчики событий, которые не удаляются, в случае если список динамический и часто меняется ( корзина товаров, например ).
Легче тогда кнопке передать этот самый
keyи потом по нему найти. Обработчик один, то что есть поиск, так он в любом случае будет, если мы работаем только с ключом.Осталось написать разработчику этой игры и выслать пропатченный вариант. Тогда миссия будет считаться законченной и вы получите "+ репутации в банде"
Ставить такие условия — заведомо готовить команду к производственному аду и придумыванием всяких правил. Причём, некоторый процент из списка, укладывается и в обычный темп разработки ( ревью кода, отношения внутри команды )
Я так понимаю, что отсутствие чата намекает на то, что играть нужно будет все равно локально? Просто с запущенным сервером. Иначе это просто "угадай и ткни"
А можно ссылочку, стало интересно)
Ну, в реальной жизни так же. Вы знаете, что 3 кнопка отдает еду. И вдруг она перестала работать, вам придется снова перенажимать все кнопки, что бы понять, где теперь новая кнопка, дающая еду.
Если увеличить
learningRateдо 1, то нейросеть будет запоминать это с первой попытки.Нажимали 3 кнопку >
Получала еду >
Кнопку поменяли >
Перенажимали все кнопки, пока не нашли новую >
Нажимаем теперь ее
Без рабочей демки как то пресно(