Будет круто если заведёте маленький дев блок в телеге, где можно делать и читать микропосты по процессу, особенно интересны как раз не столько технические аспекты, сколько бытовые проблемы при разработке в соло и совмещением с работой
Да, смотрю на него, видел сборку с ним, 4090 влезла хоть и с условиями некоторыми
Для работы я ноут использую и хватает с головой, ПК хотелось бы сугубо для VR и игр с нейронками, и тут важно, чтобы он хотя бы просто помещался в ручную кладь
Т.е. не будет существенной просадки производительности по сравнению с прямым подключением к матери через сокет? Мне как раз нужно собрать компактный ПК в связи с частыми переездами, и интересно есть ли смысл в таких вот решениях
Личное отношение может быть разным, но у компании широкий пулл активов, от MY.GAMES с ВК и Одноклассниками, до всяких Ситимобилов, YouDrive и прочих, с чего бы им умереть?
Тоже до мака было куча ноутов и тачпад использовал только в поездках, а так на столе всегда мышь, и на маководов без мыши смотрел как на безумцев… Пока не пересел за мак. Теперь мышь пылится на полке.
Полагаю тут дело больше в ПО, чем в самом тачпаде, очень уж плавно и приятно работает. Ну и ещё поверхность тактильно очень приятна. Обычно или шершавая или глянцево-скрипучая, что раздражает.
Какие-то цифры из головы. Читаем что такое event loop и понимаем что никакого «фиксированнго» значения по времени мы не получим.
Согласен, действительно складывается впечатление, что я имею в виду некую фиксированную задержку, в то время как я говорил о возможной минимальной задержке. Впрочем, с цифрой для действительно современных браузеров я тоже загнул...
Сторонние компоненты и полифиллы я намеренно не рассматривал, только то, что идёт из коробки. Спасибо что дополнили примером.
1) В 1.5 практически нету breakes changes, все они находятся в версиях 1.3-1.4, а мигрировать с 1.2 на 1.5 как-то надо, поэтому актуальность тема сохраняет. Объём фич так же в последней версии намного меньше, а описать предыдущие стоило.
2) Ну чего статье пропадать, коль уж была написана, даже если поможет одному человеку — уже хорошо :)
Миграцию я описывал не потому, что мне делать нечего, а потому, что у меня большой опыт миграции достаточно крупных проектов с кучей legacy кода, этим опытом я хотел поделиться. Касательно второй версии у меня пока такого опыта (увы) нет.
Для демонстрации создал этот небольшой пример, как видно на примере, изменение stateful не ведёт к вызову stateless, и наоборот, изменение stateless вызывает срабатывание stateful фильтра, при том что обычный stateless фильтр отрабатывает только один раз.
Ну на вскидку, у нас есть динамический список №1 и в одном из мест где его надо выводить, есть некий чёрный список №2 через который этот первый список фильтруется, при этом сам чёрный список тоже зависит от того что у нас в №1. Разумеется, всё это можно написать так, чтобы отдать в фильтр конечные данные, а не вызывать получение чёрного списка №2 внутри непосредственно фильтра, но случаи разные бывают, как и извращенцы, поэтому такая возможность разработчиками учтена :)
Ещё добавлю от себя (по скольку тут не нашёл), что в новых версиях с фильтрами всё обстоит лучше в плане выполнения в каждом цикле, поскольку для них введено состояние stateless, по умолчанию все фильтры являются именно такими.
Приведу выдержку из так и не опубликованной статьи (хотя могу и полностью опубликовать, если для кого-то это будет полезным):
Динамические фильтры
Здесь речь пойдёт о фильтрах преимущественно завязанных на данных приходящих "извне" и не зависящих от выражения (expression) к которому привязан фильтр (filter), например, фильтр который использует внутри себя некий сервис.
В версии до 1.3 фильтры были довольно глупыми и навешивая на выражение вотчер они постоянно заново вычисляли результат этого фильтра. Это одна из причин почему не стоит использовать множество фильтров в одном месте, нагружая лишней работой цикл $digest и одна из причин, почему новые фильтры работают быстрее. В новой версии фильтры ведут себя куда умнее и не вычисляют значение фильтра до тех пор, пока не изменится выражение к которому привязан данный фильтр.
Однако возникает проблема, как обновить значение фильтра, если оно зависит не только от выражения, но и от каких-то внешних факторов? Иными словами, как вернуть фильтру своё старое, "глупое" поведение, когда нам это нужно?
Для этого в 1.3 были введены понятия статичного (stateless) и динамического (stateful) фильтров.
По умолчанию фильтр ведёт себя как stateless. Сменить его поведение можно выставив нашему фильтру флаг $stateful в true.
Внимательный читатель мог заметить, что такое изменение по сути может сломать поведение старых динамических фильтров. К сожалению, я забыл описать эту особенность в первой части, но такую возможность стоит учесть.
13. Используйте фильтры как хэндлеры при изменении дайджеста!
14. Изменяйте контекст всего $scope прямо внутри фильтра через this. Ваша версия ангуляра не даёт этого сделать? Прокидывайте контекст прямо внутрь через аргументы и изменяйте снова!
Все наши знания не принципиально новые, всё новое это трасформированный продукт умственной деятельности множества поколений людей
Про принципиально новое, навскидку вот https://blog.google/technology/ai/google-deepmind-isomorphic-alphafold-3-ai-model/#life-molecules и вот https://deepmind.google/discover/blog/millions-of-new-materials-discovered-with-deep-learning/, первое про предсказание структур белков вместе с ДНК, РНК, лиганд и тем как они взаимодействуют, второе про предсказание структур кристаллов, в том числе стабильных, на нахождение которых "естественным" путём ушли бы столетия
Будет круто если заведёте маленький дев блок в телеге, где можно делать и читать микропосты по процессу, особенно интересны как раз не столько технические аспекты, сколько бытовые проблемы при разработке в соло и совмещением с работой
Удачи с проектом, главное не бросайте!
Если в бочке будет человек отвественный за освоение денег сабжа, то и денег не пожалею, чего уж там, всё для слуг народа
Да, смотрю на него, видел сборку с ним, 4090 влезла хоть и с условиями некоторыми
Для работы я ноут использую и хватает с головой, ПК хотелось бы сугубо для VR и игр с нейронками, и тут важно, чтобы он хотя бы просто помещался в ручную кладь
https://www.youtube.com/watch?v=PZD5DQpKrGM&t=726s&ab_channel=PCCentric
Т.е. не будет существенной просадки производительности по сравнению с прямым подключением к матери через сокет? Мне как раз нужно собрать компактный ПК в связи с частыми переездами, и интересно есть ли смысл в таких вот решениях
Очень ограниченный взгляд на мир
Работаю с 14ти лет, в универ не пошёл, сейчас уже 15 лет как программист и ничего не мешает мне разбираться в самых разных областях знаний
Личное отношение может быть разным, но у компании широкий пулл активов, от MY.GAMES с ВК и Одноклассниками, до всяких Ситимобилов, YouDrive и прочих, с чего бы им умереть?
Если до него за 5 лет не дойдёт его ошибка, то у меня для него плохие новости
Шёл 2018ый год, люди всё так же сокрушались о особенностях JS, вместо того, чтобы прочитать спеку, запомнить пару мелочей, смириться и перестать.
Будет ли доклад Вячеслава Слинько выложен в свободный доступ? В данный момент его нет среди прочих
Тоже до мака было куча ноутов и тачпад использовал только в поездках, а так на столе всегда мышь, и на маководов без мыши смотрел как на безумцев… Пока не пересел за мак. Теперь мышь пылится на полке.
Полагаю тут дело больше в ПО, чем в самом тачпаде, очень уж плавно и приятно работает. Ну и ещё поверхность тактильно очень приятна. Обычно или шершавая или глянцево-скрипучая, что раздражает.
Про .map хорошо подметили, если не важна мутабельность, тогда уж использовать map по назначению, и тогда всё выглядит ещё более читабельно:
Вместо
С object spread будет
или если spread режет глаз
Если всё-таки важна мутабельность и сохранение цепочки, то Object.assign снова же можно заюзать
Пусть теперь все те религиозные деятели и судьи государств, осуждающие работу со стволовыми клетками, скажут это в лицо спасённым людям.
Одна из самых крутых вещей за последнее время, а я о ней впервые слышу…
Огромное спасибо за перевод, голова кругом от открывающихся возможностей, реализуй они задуманное.
Давно задумываются и не только, просто это очень долгий процесс
Согласен, действительно складывается впечатление, что я имею в виду некую фиксированную задержку, в то время как я говорил о возможной минимальной задержке. Впрочем, с цифрой для действительно современных браузеров я тоже загнул...
Сторонние компоненты и полифиллы я намеренно не рассматривал, только то, что идёт из коробки. Спасибо что дополнили примером.
А я поясню логику, почему опубликовал:
1) В 1.5 практически нету breakes changes, все они находятся в версиях 1.3-1.4, а мигрировать с 1.2 на 1.5 как-то надо, поэтому актуальность тема сохраняет. Объём фич так же в последней версии намного меньше, а описать предыдущие стоило.
2) Ну чего статье пропадать, коль уж была написана, даже если поможет одному человеку — уже хорошо :)
Миграцию я описывал не потому, что мне делать нечего, а потому, что у меня большой опыт миграции достаточно крупных проектов с кучей legacy кода, этим опытом я хотел поделиться. Касательно второй версии у меня пока такого опыта (увы) нет.
Для демонстрации создал этот небольшой пример, как видно на примере, изменение stateful не ведёт к вызову stateless, и наоборот, изменение stateless вызывает срабатывание stateful фильтра, при том что обычный stateless фильтр отрабатывает только один раз.
Да, пожалуйста.
Ещё добавлю от себя (по скольку тут не нашёл), что в новых версиях с фильтрами всё обстоит лучше в плане выполнения в каждом цикле, поскольку для них введено состояние stateless, по умолчанию все фильтры являются именно такими.
Приведу выдержку из так и не опубликованной статьи (хотя могу и полностью опубликовать, если для кого-то это будет полезным):
Динамические фильтры
Здесь речь пойдёт о фильтрах преимущественно завязанных на данных приходящих "извне" и не зависящих от выражения (
expression
) к которому привязан фильтр (filter
), например, фильтр который использует внутри себя некий сервис.В версии до 1.3 фильтры были довольно глупыми и навешивая на выражение вотчер они постоянно заново вычисляли результат этого фильтра. Это одна из причин почему не стоит использовать множество фильтров в одном месте, нагружая лишней работой цикл
$digest
и одна из причин, почему новые фильтры работают быстрее. В новой версии фильтры ведут себя куда умнее и не вычисляют значение фильтра до тех пор, пока не изменится выражение к которому привязан данный фильтр.Однако возникает проблема, как обновить значение фильтра, если оно зависит не только от выражения, но и от каких-то внешних факторов? Иными словами, как вернуть фильтру своё старое, "глупое" поведение, когда нам это нужно?
Для этого в 1.3 были введены понятия статичного (
stateless
) и динамического (stateful
) фильтров.По умолчанию фильтр ведёт себя как
stateless
. Сменить его поведение можно выставив нашему фильтру флаг$stateful
вtrue
.Пример:
Breaking change:
Внимательный читатель мог заметить, что такое изменение по сути может сломать поведение старых динамических фильтров. К сожалению, я забыл описать эту особенность в первой части, но такую возможность стоит учесть.
13. Используйте фильтры как хэндлеры при изменении дайджеста!
14. Изменяйте контекст всего $scope прямо внутри фильтра через this. Ваша версия ангуляра не даёт этого сделать? Прокидывайте контекст прямо внутрь через аргументы и изменяйте снова!