демку я видел, и она далека от совершенства.
«почему бы мне не потратить» — вопрос настолько же некорректный, насколько и «почему бы вам не потратить».
я не вижу смысла в реализации этой единицы измерения в CSS без более низкоуровневой поддержки браузерами.
то ситуация будет не хуже, чем сейчас, когда перед экраном несколько человек. можно рассчитывать среднее, медиану, или под самого ближнего/дальнего человека. зависит от специфики устройства.
когда шрифт мелковат, есть стандартный жест — «щепотка». ну и я лишь предлагаю концепт. наверняка, если этот подход когда-нибудь реализуют, то с оговорками. к примеру, задержкой ответного изменения размеров относительно движения девайса. мыслей на эту тему много.
по ссылке — техническая реализация события трекинга лица. фактически это — технология, лежащая в фундаменте того, что я описываю. А я описываю этот подход через CSS-свойства.
Сложилось впечатление, что фейсбуковцы переизобрели велосипед. Посмотрите на подход рендеринга Ember.js или динамический рендеринг Joosy. Он делает абсолютно то же самое, только прозрачно для пользователя: bind и dispatch магически происходят внутри фреймворков.
Единственный принципиальный плюс в решении от FB — это рендеринг через React с виртуальным DOM, и тот под глубоким сомнением. Насколько реально широк тот кейс, когда данные меняются, но не меняется отображение? И реально ли такая оптимизация _заметна_ пользователю, или её можно заметить только профайлером?
я вот сейчас рискую огрести за оффтопик и холивор, но ИМХО любой палач должен отвечать за приведённый им в действие заведомо несправедливый приговор. как и любой солдат должен отвечать за свои действия на войне (почему отговорки «я просто выполнял приказ» не работают).
в «нагруженных проектах» обычно ничего не удаляется, потому что либо а) информация может потребоваться как архивная (см. финансовые приложения), либо б) Большой Брат (см. социальные сети).
аргументы про дорогое удаление, перестройку индексов и т.п. легко разбиваются пониманием того, что на перестройку индексов при добавлении записи никто почему-то не скупится.
вот именно в приведённом примере не вижу вообще никаких причин использовать find_each.
а вообще, в 4.2 обещают какую-то адскую оптимизацию AR, надо на днях поэкспериментировать.
Говоря о AR, я бы ещё упомянул всяческие touch и inc.
И что касается find_each, вы как-то слишком трепетно к нему относитесь. Инструмент хороший, когда вам нужно сделать рассылку по таблице пользователей из нескольких десятков тысяч записей. И совершенно неуместный, когда вам нужно вывести на странице 20 записей.
а я вот хочу узнать следующую вещь:
объясните, зачем функции file и list присваиваются в конструкторе? почему они не устанавливаются через prototype?
ведь, если я не ошибаюсь, в данном случае при создании двух и более инстансов App в каждом и них под эти функции будет выделен отдельный кусок памяти.
«почему бы мне не потратить» — вопрос настолько же некорректный, насколько и «почему бы вам не потратить».
я не вижу смысла в реализации этой единицы измерения в CSS без более низкоуровневой поддержки браузерами.
Объясните, как с помощью пользовательского подхода определить простое правило: комментарии могут писать только пользователи с положительным рейтингом.
Единственный принципиальный плюс в решении от FB — это рендеринг через React с виртуальным DOM, и тот под глубоким сомнением. Насколько реально широк тот кейс, когда данные меняются, но не меняется отображение? И реально ли такая оптимизация _заметна_ пользователю, или её можно заметить только профайлером?
из координат мыши в Sender'е вестимо
аргументы про дорогое удаление, перестройку индексов и т.п. легко разбиваются пониманием того, что на перестройку индексов при добавлении записи никто почему-то не скупится.
а вообще, в 4.2 обещают какую-то адскую оптимизацию AR, надо на днях поэкспериментировать.
И что касается find_each, вы как-то слишком трепетно к нему относитесь. Инструмент хороший, когда вам нужно сделать рассылку по таблице пользователей из нескольких десятков тысяч записей. И совершенно неуместный, когда вам нужно вывести на странице 20 записей.
объясните, зачем функции file и list присваиваются в конструкторе? почему они не устанавливаются через prototype?
ведь, если я не ошибаюсь, в данном случае при создании двух и более инстансов App в каждом и них под эти функции будет выделен отдельный кусок памяти.