История 4го места на Russian AI Cup 2020

А лечить лучников не кто не пробывал? И сколько за такт лечит один строить?

История 4го места на Russian AI Cup 2020

Прочитал на одном дыхание! Спасибо за столь подробный рассказ.
Узнал об этом соревновании только из вашей статьи. Возник ворпос, инересно, а имеет ли место быть стратегия, когда лучники выстаиваются свиньей.

Накидал в фотошопе пример

Как бы лучникам нужно сделать лишний шаг, но зато увеличавается их плотность. Или такая тактика не получилась бы из за слишком быстрого умирания лучников от выстелов?

Поведениеметр

Если прям совсем начинать сначала то я посоветовал бы книгу если с ребенком трудно Петрановской. До этого читал Гиппенрейтер, Курпатова, Комаровского и еще примерно 30 разных книг.

Поведениеметр

Я считаю что это временное решение и основную проблему оно не решает. А проблема тут не в ребенка, а в родителях. А если делать поведение метр то тогда нужно было их делать сразу два: один для ребенка, а другой для себя! (и я не один так думаю: eimrine) Чтобы сам ребенок тоже ставил вам оценки за поведение, а то вдруг вы тоже не дотягиваете. Вдруг вам тоже надо что-то в нем подкорректировать.

Тоже пробывали внеднять подобные методы оценки поведения ребенка. Но и попутно читать литературу, а все ли мы, как родители, делаем правильно. И выяснилось что многое чего делали не правильно. Исправили свое поведение, и о чудо, поведение ребенка тоже изменилось в лучшую сторону.

А переделывать себя сложно!

Делаем схему выбора мест в кинозале на React: о canvas, красивом дизайне и оптимизации

За статью конечно спасибо! Давно ждал нечто подобного, что кто-то возьмет, и сделает это: скрестит React и Canvas. В добавок тема отрисовки концертных залов мне знакома (фулстек разработчик Myslo-кассы).

Года 4 назад нужно было создать инструмент, для продажи билетов. Тоже был выбор SVG или canvas. Делать на чистом HTML не рассматривал как вариант, потому что там ожидали проблема с масштабированием. В тот момент как раз Павел Дуров устраивал как раз конкурс на отрисовку графиков, и там как раз в чатах была борьба, какой механизм отрисовки лучше: SVG или canvas. SVG проиграл. Поэтому я выбрал canvas.

Я выбрал делать на canvas в нативе (canvas 2D). На тот момент образцом для подражания была афиша яндекса с монстуозной схемой. У нее был только один минус -все очень сильно тормозило. Одним из требований было то что это все должно работать очень быстро. В итоге, выбор сектора были сделан на SVG, а выбор мест на canvas (пример можно посмотреть тут как работает схема зала).

Нюансы при отрисовки:

1. Не отрисовывать места которые выходят за пределы области canvas
2. Не делать лишних перерендеров, перерендер выполняется только по внешнему событию: перемещение схемы, изменение масштаба, изменение размера страницы.
3. FPS при отрисовки схема должен быть 60 кадров в секунду!

Пожалуй FPS было самым главным требованием! Да, схема зала получилась очень простой, но отрисовка мест происходит очень быстро.

Выводы которые сделал я:

1. SVG — это максимум 1000 элементов в DOM дереве — все остальное медленно.
2. canvas — отрисовка в 5000 областей за раз не вызывает просидания FPS. Все что больше требует принятия дополнительных мер: дробить цикл на кадры, кеширование областей.
3. Избегать отрисовки больше 1000 мест на одном экране.

Я решил посмотреть как это работает на вашем сайте, на примере этого мероприятия. Сразу пройдусь по багам которые заметил:

1. Шаг изменения масштаба зала происходит очень резко: есть вариант с выводом всего зала и сразу с супер увеличением.
2. Из 2 вытекает проблема что если нужно выбрать место с краю, нужно drug&drop-ом двигать схему зала. И тут конечно заметно просидание FPS по отрисовки на Core i5! По ощущению, ну кадров 5 в секунду (Firefox, в хроме лучше).
3. Меняем размер страницы и все зависает, а потом загружается начальная страница.
4. Запаздывающий эффект наведения.
5. Возможность выбора мест на начальной схеме зала без увеличения масштаба. Каждое место на экране занимает ровно 3 пикселя. Я не думаю что это удобный способ выбора мест. Тем более в этом режиме однозначно будут просидания в производительности

Низкий FPS

Запаздывающий эффект наведения

Выбор мест на начальной схеме зала

Выводы:

1. В целом конечно видно, что все еще очень сырое. Вчера выкатили, а сегодня написали статью. Этот комментарий я хотел написать еще вчера, но я просто не мог не посмотреть как работает схема потому что она просто падала, с ошибкой связаной с booking. Схема зала не работала не в одном из опробованных браузеров.
2. Мне кажется Pixi нужно менять на что-то другое (возможно свое). Возможно стоит делать отрисовку только на canvas 2D, раз 3D не используется. Canvas отрисовку нужно хорошенько кешировать, тогда она будет работать быстро.
3. За React нужно конечно тщательно следить, потому что с ним очень просто наделать кучу лишних перерендеров.
4. На счет максимального кол-ве мест в зале — нужно было выбирать олимпийский — и пытаться отрисовать их 3 на одном экране. Здесь конечно, мне кажется, нужно использовать какой то механизм создания контура секторов исходя из координат мест, и на большой схеме показывать только эти контуры, а при увеличении уже подгружать места для секторов. Тогда не будет проблемы отрисовки больше 1000 мест на одном экране и показ первого экрана станет быстрее. В своей реализации, я пытался тоже сделать механизм автоматического создания контуров, но потом счет это слишком сложной задачей.

Анонимный Дед Мороз 2020-2021: пост хвастовства новогодними подарками

Первый год участвую анонимным дедом морозом. Очень рад, что присоединился к этой славной традиции. Было даже немного волнительно. А когда я узнал, что мои олени скачут из самой родины деда мороза — Великого Устюга, тут сложно не поверить в новогоднее чудо!

Самое время заглянуть внутрь

Дети слопали за раз пол коробки зефира! Я первый раз попробовал зефир с начинкой, в моем городе таких не где не встречал. Свечку сразу жена забрала. Травяные чаи я обожаю! Спасибо тебе Дедушка!

С наступающим Новым Годом!

Service Workers

Жалко что поддержка SyncManager реализована только в хромо-подобных браузерах.

Все ли вы знаете о useCallback

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

Ну не хотите вы использовать useCallback — ну так и не используйте! Это ваше право, ваш выбор! Я не заставляю вас делать этого в каждом компоненте. React рекомендует использовать useCallback но не заставляет. Дедлайны горят! Больше кода надо писать! Не видите в этом пользы! Ну так и не делайте! Я вас ругать не буду! Правда!

А кому надо?

Этот надо мне!

И зачем?

Чтобы перерендер работал быстрее!

Чего вы добились этим кодом?

Чтобы было легче переиспользовать код! Чаще всего, я сталкиваюсь с задачами, когда я не знаю что там происходить в компонентах ниже/выше по дереву (писал больше пол года назад, либо писал другой человек). А там может быть не только removeEventListener/addEventListener но другие вещи. Моя задача написать такой код, который бы делал минимальное число лишних перерендеров. Поэтому я использую useCallback.

Все ли вы знаете о useCallback

Вот то что было написано в вашем примере:
const onClick = () => onCarClick(car);
А вот, так как надо делать с точки зрения React:
const onClick = useCallback(() => onCarClick(car), [car]);

При первом рендеренге, в обоих случаях, будет создана ссылка на функцию onClick.
При повторном рендеренге onClick, созданная без useCallback, будет содержать новую ссылку на анонимную функцию.
А вот при повторном рендеренге onClick, созданная через useCallback, будет содержать туже ссылку на анонимную функцию. В этом и есть магии функции useCallback! Задача useCallback состоит в том чтобы ссылка на функцию внутри не менялась при отсутствии изменений в deps

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

Все ли вы знаете о useCallback

Внимание вопрос
В каком из вариантов написания компонента функция присваемая переменной someFunction создается реже?

У меня тоже вопрос: зачем все это? Для чего вам уменьшать кол-во присвоений функции?

Может вы хотите сказать о производительности? Ну так сделайте бенчмарки, можно будет увидеть реальное сравнение в скорости и сделать какие то выводы.

Примеры, которые вы приводите, оставляют желать лучшего. Вместо вот этого:

const Cars = ({ cars }) => {
  const onCarClick = (car) => {
    console.log(car.model);
  }

  return cars.map((car) => {
    return (
      <Car key={car.id} car={car} onCarClick={onCarClick} />
    )
  });
}

можно вообще переписать так:

const onCarClick = (car) => {
  console.log(car.model);
}
const Cars = ({ cars }) => {
  return cars.map((car) => {
    return (
      <Car key={car.id} car={car} onCarClick={onCarClick} />
    )
  });
}

Зачем класть функцию onCarClick, внутрь Cars, если ссылка на нее не зависит от props? onCarClick — это чистая функция.

А ниже вы тоже приводите странный листинг кода:

const Car = ({ car, onCarClick }) => {
  const onClick = () => onCarClick(car);

  return (
    <button onClick={onClick}>{car.model}</button>
  )
}

Этот код можно переписать так:

const Car = ({ car, onCarClick }) => {
  const onClick = useCallback(() => onCarClick(car), [car]);

  return (
    <button onClick={onClick}>{car.model}</button>
  )
}

Здесь функция onClick явно зависит от props. Чтобы React не делал лишнего рендера нужно чтобы ссылка на функцию onClick не менялась, при передачи одного и того же значения. А добиться этого как раз можно используя useCallback.

Я переписал окончательный вариант на колбеках:

const Cars = ({ cars }) => {
  const onCarClick = useCallback((car) => {
    console.log(car.model);
  }, []);

  return cars.map((car) => {
    return (
      <Car key={car.id} car={car} onCarClick={onCarClick} />
    )
  });
}

const Car = ({ car, onCarClick }) => {
  const onClick = useCallback(() => onCarClick(car), [car]);

  return (
    <button onClick={onClick}>{car.model}</button>
  )
}

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

В том то и дело что польза есть! Примеры, которые вы приводите, содержат фундаментальные ошибки.

Я использую VSCode с плагином ESLint на который установлено специальное дополнение по автоисправлению всех зависимостей хуков (link).

Как показывать ИБ в 2021 году, чтобы ваш сериал не провалился

Если создатели сериалов про хакеров и киберпреступность не прорабатывают детали, перед экраном грустит один кибербезопасник.

Еще грустит физик.

Некст не смотрел, но вот по Devs без фейспалмов не обойтись.

1. Откуда в кубе берется кислород? По летающему лифту доставляется наверно...
2. Какие должны быть магниты, чтобы создать магнитное поле для удержания огромного куба на расстоянии 7 метров и при этом не как не воздействовать на все остальные металлические предметы, ну даже часы с камерой нового прогера?
3. Куб висит в вакууме, проводов нет. Внутри куба откуда то берется электричество. Предположим что это индукция. Куда отводить тепло, вырабатываемое квантовым компьютером, находясь в вакууме? На лифте катать?

Самодельный гироскутер

А что вы имеете против софта на ардуино?

Новый сайт для популярного медиа за 2 месяца

Жалко что о технических деталях реализации не сказано почти ни слова, а очень хотелось бы.

Очень большой Time to Interactive — на телефоне, после показа шапки, очень долго ничего не проихсодит. Я вижу секунд 5-10 просто шапку с логотипом и просто чистый лист. По ощущению, идет компиляция страницы для первоначального отображения. Причем нагрузка на трафик не сильная, а вот нагрузка на проц просто чудовищная. Такая же проблема хорошо заметна и на десктопе, если немного опустить скорость работы процессора.

Определенно стоит провести оптимизацию показа первого экрана. Мне кажется слишком много там сейчас выполняется фоновых действий, которые съедают ресурсы проца, откладывая первый показ.

По возможности отложить загрузку модулей, которые не нужны для первого показа. Например на главной не обязательно знать как рендерить конкретную новость, а в новости не обязательно знать как рендерить главную. Здесь лучше всего использовать модель загрузки lazy load module

Пред компиляции готовых HTML страниц нет — это конечно плохо.

Общий вывод:
Плиточный дизайн в стиле медузы конечно хорошо. Отсутствие пред компиляции страниц и очень тяжелые скрипты рендера приводят к большим задержкам первого показа. Сайт кажется очень тяжелым, но при этом ничего такого сверх тяжелого на нем я не вижу. Если выявить проблемы со скоростью рендера, то это, мне кажется, может существенно сократить время первого показа.

Новый плацкарт в вагоне габарита Т: помните ту обратную связь, что вы давали на 1-ВМ?

Да, рисовал все в формате Т.

На счет скорости ничего сказать не могу, в статье было что новые вагоны должны будут так же рассчитаны на стандартные ограничения по скорости в 160км/ч, Значит можно формату Т 160км/ч гонять.

Считаете, что для более длительных поездок старый добрый плацкарт, с ногами в проходе и новыми знакомыми будет предпочтительнее?

В одной из статей было первоначальное т.з. и там как раз было написано про это.

По поводу инстилляции еще ладно, там проще, а вот на счет отопления индивидуального думаю врятли. Чисто технически это сделать сложно. Здесь на хабре, была статья в которой как раз писали почему до сих пор вагоны отапливают дровами.

На счет двух рядов окон, ну так все уже и так есть в двухэтажных вагонах

Новый плацкарт в вагоне габарита Т: помните ту обратную связь, что вы давали на 1-ВМ?

Комментарии ваши прочитал, все по делу!

На счет столика можно и стационарный:

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

Программа SketchUp

Отвечу тут сразу и на нижние вопросы по размерам:
Ширина внутренняя — 3220мм — не помню уже откуда ее взял, так что может она реально больше того что есть на самом деле. Шаг елочки — 1155мм. Длинна всех девяти купе я где то нашел — 16173 мм. Если 16173 поделить на 14 как раз получится 1155мм. Тут еще нюанс в том, число купе не сходится со старой системой (54 против 56), если делать по одинаковому числу купе на каждой стороне. Угол наклона 35.2 градуса — почти как у вас! Ширина полки 637мм — в самом узком месте 645мм у меня получилось (это с учетом межкупейных стенок по 30мм.).

Как по мне, данный дизайн устраняет практически все известные недостатки плацкарта — короткие полки, отсутствие частного пространства, расположение боковых мест в проходе. Пространства под нижней полкой (около 400 л) должно быть достаточно для багажа, даже для лыж и, возможно, байдарок. Для велосипедов можно предусмотреть сетчатую полку на уровне 205 см сразу у тамбура.

Вот именно, абсолютно с вами согласен! На счет велика, сам как велосипедист, могу сказать что велик на самом деле довольно быстро разбирается. Снять колеса и примотать их к раме займет 10 минут, руль тоже держится на двух болтах и тоже быстро снимается обычным шестигранником. Конечно велосипедисты народ тот еще упрямый, поэтому предвижу что в меня могут полететь педали помидоры.

Мне кажется, вариант елочкой игнорят потому что изначально были большие ограничения по редизайну. Там где то в посте или в комментариях писали, что изначально было условие, что нужно придумать новый дизайн плацкартного вагона не изменяя вагон внешне: окна должны были оставаться на своих местах, система вентиляции не должна была меняться. Отсюда и пошло поехало что практически ничего трогать то и нельзя. Даже этот рундук между полками в купе мешал нормальной работе штатной вентиляции. Поэтому сказали что нужно тогда делать индивидуальную вентиляцию. Ок. Сделали индивидуальную вентиляцию, а потом еще и выяснилось что уж наверно проще и вообще весь вагон тогда переделать, пересчитать все его размеры и характеристики: окна наконец сделать нормальными чтобы на верхней полке можно было в него что-то видеть кроме рельс. В итоге мы получаем совершенно новый вагон, но со всеми старо-новыми идеями, в виде рундука между полками. Ну ведь жалко этот рундук выкидывать на свалку идей! Его вон уже и в реальном вагоне сделали и вроде как норм. Вот видимо и решили что все, ничего менять не будем больше, типо хватит. Но я считаю такой подход в корне не верный — раз есть новые размеры вагона — так надо выкинуть все идем и взглянуть на возможный результат с нуля — с чистого листа! Расписать все за и против каждого возможного варианта ну и какой вариант больше наберет положительных сторон тот и выбрать.

Для однодневных поездок на одну ночь вариант с елочкой мне кажется более оптимальным. В нем не надо ползать по полке, потому что из положения сидя, в положении лежа оказаться намного проще. Полка на втором ярусе с рундуком подразумевает что у человека должны быть довольно сильные руки чтобы он мог на них не только опираться, но и протаскивать ими собственное тело.

Новый плацкарт в вагоне габарита Т: помните ту обратную связь, что вы давали на 1-ВМ?

И все таки формат расположения спальных мест елочкой мне понравился больше.
Раз уж переходите на новый формат размеров вагонов, то тут просто отличная возможность разгуляться с новыми форматами компоновки спальных мест.

Посмотрев видео китайского вагона (спасибо Animegravitation), я решил потратить вечерок и нарисовать что-то в этом же стиле.

Много фото под спойлером:

Размеры взяты приблизительные из википедии и разных источников. В результате спальное место в самой длинной точке достигает фантастических 2100 мм. Ширина спального места получилась 636мм. На верхней полке осталась лишь одна полка для чемодана. На нижней полка + пространство под кроватью. На нижней полке можно опустить ноги перед окном и смотреть в окно. Длинна всех 9 купе была взята 16173мм. На одной стороне уместилось 14 двухъярусных купе. Итого — 56 мест.

Книга «Хороший интерфейс — невидимый интерфейс»

Я хочу попить чаю! Мне нужно включить чайник.
Но погодите, у меня же супер чайник с Bluetooth

1. Найти телефон, где я последний раз оставил его в квартире;
2. Нужно аккуратно взять телефон чтобы телефон не упал и не разбился о пол;
3. Разблокировать телефон;
4. Свернуть последнее приложение;
5. Прокрутить экран до иконки с приложением по запуску чайника;
6. Нажать на него;
7. Смотрим на заставку приложения 5 секунд;
8. Смотрим на лоадер загрузки моих домашних устройств еще 5 секунд;
9. Выбираю чайник из списка устройств;
10. Идет подключение по блютуз к чайнику — 5 секунд;
11. Выбираю в меню "кипячение";
12. Нажимаю на кнопку "включение".

Вместо того чтобы:

1. Подойти к чайнику;
2. Включить чайник.

Спасибо за ссылку!

Старт работы с Excel на C#

Я использую ClosedXML — бесплатный софт по работе с Excel. В основном Excel используем для генерации отчетов и дальнейшей печати, так как с PDF немного сложнее и дольше работать. По скорости работы замеры не делал.

Дерево синтаксиса и альтернатива LINQ при взаимодействии с базами данных SQL

Вообще конечно я перед вами снимаю шляпу! Такую крутую библиотеку написали. Самому давно хотелось написать нечто подобное, но к сожалению, не обладаю такими глубокими познаниями в шарпе. Фильтры на выборку данных приходится писать довольно часто, но я до сих пор не нашел ответа на простой вопрос, как в LINQ сделать выборку из таблицы по полю, которое было передано в переменной? (если вы может где видели, был бы рад ссылочки).

На счет LEFT JOIN это действительно магия какая то, тоже постоянно лезу в гугл.

Вообще конечно, из личного считаю, считаю LINQ в Entity Framework ужасной штукой. Он как наркотик, подсаживает на быстроту и удобство доставания данных, но когда дело доходит до оптимизаций, или каких то специфических вещей, то тут только понимаешь, что пора с него слезать. Иногда слезать бывает сложно, и дело доходит до подобных вещей. У меня был опыт, когда джун протащил во вьюшку модельку, которую отдал EF, и потом прямо на вьюшке делал циклические подзапросы с помощью lazy loading.

Другой раз фильтры организовать, как в начале вашей статьи. Сделать что-то универсальное ну практически не возможно. Только копипаст. Ну ведь хочется, сделать красиво, не писать один и тот же код дважды, но нет, тут так нельзя, нужно копипастить.

Из последнего, есть у меня два больших Select(n => ModelA и Select(n => ModelB.
ModelA состоит из 50 полей и ModelB состоит из 50 полей и лишь одно поле у них разное. Только одно поле! Но объединить их из под LINQ запрос не как не получится. Тут либо оба поля всегда дергать и не важно, нужно оно там дальше или нет. Либо две разные модели но фактически одного и того же. Если бы я был в мире обычного SQL мне бы удалось достичь подобного парой строк кода, но в мире LINQ over EF, только копипаст. Всерьез уже начинаю задумываться о генераторах кода, которые перед билдом будут создавать нужный код!

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

Дерево синтаксиса и альтернатива LINQ при взаимодействии с базами данных SQL

Ну а разве с помощью LINQKit нельзя сделать выборку из таблицы по полю, переданному в переменной?