Ну у меня всегда объект перерисовывается целиком — способа перерисовать кусок растра с которым мы контактировали я пока не нашел. Если вы знаете как это сделать на CANVAS — буду рад услышать и применить.
Вы же CanvasRenderingContext2D.drawImage() используете для рисования растра на канву, верно? Он умеет это всё из коробки.
Регистрация обработчиков. У вас там на каждую кнопку создаётся новая функция, которую ничего не связывает с другими кнопками и их обработчиками. Плохая практика, кстати, т.к. часто приводит к ненужным перерисовкам.
Т.е. при незначительном (с точки зрения пользователя, но не машины) изменении поискового запроса я могу получить такой же колдунщик, но от другого разработчика? Это ОК в поисковой выдаче. Там элементов много и некоторая подвижность элементов ожидаема. Но колдунщики занимают много места и на странице их 1 штука. Внезапное изменение этого элемента — не то, что я ожидаю увидеть.
Я, конечно, понимаю, что оно сейчас примерно так и происходит. Бывает, ожидаешь увидеть по запросу какой-то определённый колдунщик, а его нет. Но когда начнётся такой рандом…
Почему-то никто не задал самый интересный вопрос: чего вы хотите?
Допустим, Яндекс одумался и решил «восстановить справедливость». Чего ему делать то? Я вижу 3 варианта «восстановления»:
Дать возможность добавлять свои колдунщики. Если по поисковому запросу можно получить несколько колдунщиков — показывать все. Захочу поискать пиццерию — яндекс покажет свою карту, 2гис — свою. Потом появится карта от говнору. Да, возможность добавлять колдунщики надо будет всем, а не избранным. Иначе ведь конкуренция нечестная. В итоге поисковая выдача становится не поисковой. Я, как пользователь, страдаю.
То же самое, но показывать какой-то один колдунщик. А какой? 2Гис? Яндекс? говнору?
Как понять, что один лучше другого? Показывать говнору одним пользователям, 2Гис — другим? Ищу пиццерии — вижу 2Гис. Ищу автосалон — вижу говнору. И что, мне остаётся страдать и надеяться, что у второго рекламный бюджет кончится раньше?
Выпилить колдунщики. Совсем. Во славу справедливости и конкуренции. Я, как пользователь, опять страдаю.
Я не вижу решения ситуации (допустим, её действительно надо решать), при котором бы опыт использования поискового сервиса не страдал. Можете прояснить ваше видение решения?
Вы говорите о несколько другом случае. Длинные условия — это одно. Повторяющиеся условия — это другое. Длинные условия (метрика автора мне вполне нравится — более 2 операторов) надо выносить в переменную. Иначе интерфейс рискует быть засраным по самое не могу почем зря. Да и локальность кода сохранится. Повторяющиеся условия — выносить в методы/функции (и тут уже не важно, насколько это условие длинное).
Если условие необходимо проверять во многих местах, так и делают. Вместо переменной let userExistsAndValid = model.user && model.user.id; вводят функцию function userExistsAndValid { return model.user && model.user.id; }
Вы просто не умеете готовить табы. Они нужны для отступов. Но для выравнивания всегда нужно использовать пробелы. Пример: https://ibb.co/fTxMTQ. В итоге каждый может использовать удобную ему ширину отступа. У меня, например, она может меняться в зависимости от связки шрифт+монитор. Где-то пошире, где-то поуже. Иногда даже неканоничные значения типа 3 бывают приятны.
У пробелов есть проблема, похожая на то, что вы описали. В одном из проектов, над которыми я работаю, приняты пробелы для всего. Открываю я файл, начинаю его редактировать… А редактор облажался с определением ширины отступа и использует мои настройки. И вставляет не 4 пробела на отступ, а 2, например. Или наоборот. И такое не было редкостью. Но отображается у всех «одинаково», да. осталось только шрифт «стандартизовать» и его размер. =)
Вот только я не знаю ни одного тула, который мог бы автоматически проверить это правило, и не уверен, что они вообще существуют.
clangFormat мало того, что умеет так делать, так ещё и существует.
На моей практике проблемы с данным подходом возникают редко. И сразу видны глазу (я работаю с отображаемыми whitespace'ми уже давно. Много дольше, чем придерживаюсь системы «табы — для отступов, пробелы — для выравнивания»).
Аргумент про «будет копиться неправильный код» — это именно то, о чем говорил Goury. Тимлидам проще смириться с пробелами, чем объяснить, как пользоваться табами.
У Вас, возможно, беда с железом, а Вы и не в курсе. Долгая загрузка Lubuntu — это очень странно.
У меня тоже Ubuntu грузится долго. Потому что один вендор, не буду его называть, не осилил USB. Она, бедная, пытается проинициализировать устройство и так, и эдак, и много чего ещё делает. Венда кладёт болт. Как итог — грузится быстрее. Стоит физически отключить устройство — ситуация меняется на противоположную.
Запросто. Интерфейс может оказаться недружелюбным к различного рода кешам, требовать выполнения забавных, неоптимальных запросов к БД (именно требовать, да). Можно вспомнить про распределённость данных и необходимость их собирать с разных шард, сложность этих задач сильно разнится в зависимости от данных. Это всё будет отлично работать на фейковых и небольших наборах данных. А вот в продакшене — выстрелит. Сталкивался с таким.
И про неподдерживаемость не забывайте.
БОльшая часть проблем, описанных в статье (если не все), вытекает из отсутствия взаимодействия в команде. API должно разрабатываться всей командой. backend и frontend ДОЛЖНЫ работать сообща, иначе у них получится говно будь даже каждый из них гением в своём деле.
Вы же
CanvasRenderingContext2D.drawImage()используете для рисования растра на канву, верно? Он умеет это всё из коробки.Регистрация обработчиков. У вас там на каждую кнопку создаётся новая функция, которую ничего не связывает с другими кнопками и их обработчиками. Плохая практика, кстати, т.к. часто приводит к ненужным перерисовкам.
Я, конечно, понимаю, что оно сейчас примерно так и происходит. Бывает, ожидаешь увидеть по запросу какой-то определённый колдунщик, а его нет. Но когда начнётся такой рандом…
Допустим, Яндекс одумался и решил «восстановить справедливость». Чего ему делать то? Я вижу 3 варианта «восстановления»:
Как понять, что один лучше другого? Показывать говнору одним пользователям, 2Гис — другим? Ищу пиццерии — вижу 2Гис. Ищу автосалон — вижу говнору. И что, мне остаётся страдать и надеяться, что у второго рекламный бюджет кончится раньше?
Я не вижу решения ситуации (допустим, её действительно надо решать), при котором бы опыт использования поискового сервиса не страдал. Можете прояснить ваше видение решения?
А люди и без моей помощи себя отлично делят на группы.
let userExistsAndValid = model.user && model.user.id;
вводят функциюfunction userExistsAndValid { return model.user && model.user.id; }
У пробелов есть проблема, похожая на то, что вы описали. В одном из проектов, над которыми я работаю, приняты пробелы для всего. Открываю я файл, начинаю его редактировать… А редактор облажался с определением ширины отступа и использует мои настройки. И вставляет не 4 пробела на отступ, а 2, например. Или наоборот. И такое не было редкостью. Но отображается у всех «одинаково», да. осталось только шрифт «стандартизовать» и его размер. =)
clangFormat мало того, что умеет так делать, так ещё и существует.
На моей практике проблемы с данным подходом возникают редко. И сразу видны глазу (я работаю с отображаемыми whitespace'ми уже давно. Много дольше, чем придерживаюсь системы «табы — для отступов, пробелы — для выравнивания»).
Аргумент про «будет копиться неправильный код» — это именно то, о чем говорил Goury. Тимлидам проще смириться с пробелами, чем объяснить, как пользоваться табами.
У меня тоже Ubuntu грузится долго. Потому что один вендор, не буду его называть, не осилил USB. Она, бедная, пытается проинициализировать устройство и так, и эдак, и много чего ещё делает. Венда кладёт болт. Как итог — грузится быстрее. Стоит физически отключить устройство — ситуация меняется на противоположную.
И про неподдерживаемость не забывайте.
БОльшая часть проблем, описанных в статье (если не все), вытекает из отсутствия взаимодействия в команде. API должно разрабатываться всей командой. backend и frontend ДОЛЖНЫ работать сообща, иначе у них получится говно будь даже каждый из них гением в своём деле.