Обновить
4
0
Леготкин Алексей @ThisMan

Пользователь

Отправить сообщение

Почему вундеркиндов? Он начал программировать в 13 лет, вполне уже осознанный возраст. Естественно в 26 ( через 13 лет! ), список достижений может быть существенным.
Даже если взять его универ, уже 5 лет опыта/обучения/разработки, что не так уж и мало.


Вопрос скорее в увлеченности, трудолюбии и терпении, а тут не нужно быть вундеркиндом

Вот не совсем понятно, как это компонент использовать только в дев режиме. В проде конечному клиенту этот компонент не нужен. Хотелось бы в идеале иметь сборку с Profiler-ом и без, так сказать перфтесты. Но в текущей реализацию не понятно, как это сделать

Если используете какой-нибудь redux, значит уже использовали с помощь connect


export default connect(Component,  ...)**

В данном случае, наверное, красивее писать так


{hovering && <Tooltip id={this.props.id} />}
Тут вопрос насколько сложное приложение, если это простой ЮИ — то обычно, это все не нужно, create-react-app прекрасно будет работать, а если много бизнес логики на клиенте — это уже совсем другой опыт и тут специализированные утилиты как раз очень помогают.

Но ведь hq тоже не подойдет для больших проектов


It might help to serve small projects with very little dependencies

Чет я не совсем понял хейта по поводу бандлов. Какие-то надуманные проблемы с соурсмапами. Тот же вебпак эмулирует файловую структуру проекта через соурсмапы, так что к каждому отдельному модулю будет доступ ( даже к node_modules ) + именно для разработки есть dev-server. Ну и конфигурация: по сути своей один раз настроил и используй во всех проектах. Куча же всяких boilerplate-ов есть.


А тут: для разработки один инструмент, для прода другой. Давайте еще для тестирования придумаем что-нибудь

                    Астрологи объявили неделю ботов для вк.
      Количество постов про написание ботов на питоне увеличено в N раз.

Думаю, в данном случае, вместо мешанины из нескольких циклов можно было бы простенький конечный автомат использовать. Реализовать его как какой-нибудь класс Dialog. Тогда мы бы обошлись одним циклом. Просто бы принимали event, передавали бы его инстансу класса ( для каждого пользователя свой ), и инстанс бы сам решал, что именно нужно сделать с event.

Идея интересная, просто казалось, что longpoll будет достаточно, для того, что бы получить всю нужную инфу.

Забавно, что сам вчера начал писать бота, который выкладывает в паблик картинки, которые прислали в конфе. Правда столкнулся с проблемой, что во-первых atttachments, который приходит при событии longpoll имеет не очень удобный формат:


attachment1_type, attachment1, attachment2_type, attachment2, etc

Второе, это то что картинки, которые скинули в конфу невсегда доступны по прямой ссылке, что затрудняет их скачивание и публикацию ( если вообще не блокирует эту возможность )

Пишут, что классы «сложны для понимания», но при этом добавляют ещё одну сущность. Не думаю, что эти прям таки хороший подход. Некоторые примеры, вообще не очевидными кажутся ( например, возвращаемая функция в useEffect )

Не обязательно, достаточно Button сделать универсальной


class Button extends React.PureComponent {
  render() {
    return (
      <button onClick={this.handleClick}>{this.props.children}</button>
    )
  }
  handleClick: () => {
    const {onClick, ...others} = this.props
    onClick(others);
  }
}

Таким образом можно вообще все что угодно передавать в Button ( но лучше если это будут простые данные, типо id/key/name )

Я думал холивары про то, можно ли в обработчики компонентов стрелочные функции передавать закончился еще эдак в году 2016ом


if (!Object.prototype.hasOwnProperty.call(this.clickHandlers, key)) {
  this.clickHandlers[key] = () => alert(key);
}

Не получится так, что мы будем копить ненужные обработчики событий, которые не удаляются, в случае если список динамический и часто меняется ( корзина товаров, например ).


Легче тогда кнопке передать этот самый key и потом по нему найти. Обработчик один, то что есть поиск, так он в любом случае будет, если мы работаем только с ключом.

Осталось написать разработчику этой игры и выслать пропатченный вариант. Тогда миссия будет считаться законченной и вы получите "+ репутации в банде"

Может главная проблема в этом: «Основная наша задача – делать максимальное количество экспериментов в единицу времени и выдавать продуктовые фичи с максимально возможной скоростью.»
Ставить такие условия — заведомо готовить команду к производственному аду и придумыванием всяких правил. Причём, некоторый процент из списка, укладывается и в обычный темп разработки ( ревью кода, отношения внутри команды )

Я так понимаю, что отсутствие чата намекает на то, что играть нужно будет все равно локально? Просто с запущенным сервером. Иначе это просто "угадай и ткни"

Как то скептически отношусь ко всяким «компилируемым в JS» языкам. Мало того, что повышает порог вхождения, так ещё и приносит новые проблемы, в данном случае «биндинги не для новичков», зачем? Если есть immutable.js, где нет таких проблем

А можно ссылочку, стало интересно)

Ну, в реальной жизни так же. Вы знаете, что 3 кнопка отдает еду. И вдруг она перестала работать, вам придется снова перенажимать все кнопки, что бы понять, где теперь новая кнопка, дающая еду.
Если увеличить learningRate до 1, то нейросеть будет запоминать это с первой попытки.


Нажимали 3 кнопку >
Получала еду >
Кнопку поменяли >
Перенажимали все кнопки, пока не нашли новую >
Нажимаем теперь ее

Без рабочей демки как то пресно(

Информация

В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Дата рождения
Зарегистрирован
Активность