Pull to refresh
16
0
Al Geas @StGeass

Front-end Developer at DIWO

Send message

Если в бочке будет человек отвественный за освоение денег сабжа, то и денег не пожалею, чего уж там, всё для слуг народа

Да, смотрю на него, видел сборку с ним, 4090 влезла хоть и с условиями некоторыми

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

https://www.youtube.com/watch?v=PZD5DQpKrGM&t=726s&ab_channel=PCCentric

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

Очень ограниченный взгляд на мир

Работаю с 14ти лет, в универ не пошёл, сейчас уже 15 лет как программист и ничего не мешает мне разбираться в самых разных областях знаний

Личное отношение может быть разным, но у компании широкий пулл активов, от MY.GAMES с ВК и Одноклассниками, до всяких Ситимобилов, YouDrive и прочих, с чего бы им умереть?

Если до него за 5 лет не дойдёт его ошибка, то у меня для него плохие новости

Шёл 2018ый год, люди всё так же сокрушались о особенностях JS, вместо того, чтобы прочитать спеку, запомнить пару мелочей, смириться и перестать.

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

Надо попользоваться, чтобы понять.

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

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

Про .map хорошо подметили, если не важна мутабельность, тогда уж использовать map по назначению, и тогда всё выглядит ещё более читабельно:


Вместо


.map(prop => 
                    {
                        prop.a = prop.a * 2;
                        return prop;
                    });

С object spread будет


.map(prop => ({...prop, a: prop.a * 2}))

или если spread режет глаз


.map(prop => Object.assign({}, prop, {a: prop.a * 2}))

Если всё-таки важна мутабельность и сохранение цепочки, то Object.assign снова же можно заюзать


.map(prop => Object.assign(prop, {a: prop.a * 2}))
Потрясающе!

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

Одна из самых крутых вещей за последнее время, а я о ней впервые слышу…


Огромное спасибо за перевод, голова кругом от открывающихся возможностей, реализуй они задуманное.

Давно задумываются и не только, просто это очень долгий процесс

Какие-то цифры из головы. Читаем что такое event loop и понимаем что никакого «фиксированнго» значения по времени мы не получим.

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


Сторонние компоненты и полифиллы я намеренно не рассматривал, только то, что идёт из коробки. Спасибо что дополнили примером.

А я поясню логику, почему опубликовал:


1) В 1.5 практически нету breakes changes, все они находятся в версиях 1.3-1.4, а мигрировать с 1.2 на 1.5 как-то надо, поэтому актуальность тема сохраняет. Объём фич так же в последней версии намного меньше, а описать предыдущие стоило.
2) Ну чего статье пропадать, коль уж была написана, даже если поможет одному человеку — уже хорошо :)


Миграцию я описывал не потому, что мне делать нечего, а потому, что у меня большой опыт миграции достаточно крупных проектов с кучей legacy кода, этим опытом я хотел поделиться. Касательно второй версии у меня пока такого опыта (увы) нет.

  1. Для демонстрации создал этот небольшой пример, как видно на примере, изменение stateful не ведёт к вызову stateless, и наоборот, изменение stateless вызывает срабатывание stateful фильтра, при том что обычный stateless фильтр отрабатывает только один раз.


  2. Ну на вскидку, у нас есть динамический список №1 и в одном из мест где его надо выводить, есть некий чёрный список №2 через который этот первый список фильтруется, при этом сам чёрный список тоже зависит от того что у нас в №1. Разумеется, всё это можно написать так, чтобы отдать в фильтр конечные данные, а не вызывать получение чёрного списка №2 внутри непосредственно фильтра, но случаи разные бывают, как и извращенцы, поэтому такая возможность разработчиками учтена :)

Да, пожалуйста.


Ещё добавлю от себя (по скольку тут не нашёл), что в новых версиях с фильтрами всё обстоит лучше в плане выполнения в каждом цикле, поскольку для них введено состояние stateless, по умолчанию все фильтры являются именно такими.


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


Динамические фильтры


Здесь речь пойдёт о фильтрах преимущественно завязанных на данных приходящих "извне" и не зависящих от выражения (expression) к которому привязан фильтр (filter), например, фильтр который использует внутри себя некий сервис.


В версии до 1.3 фильтры были довольно глупыми и навешивая на выражение вотчер они постоянно заново вычисляли результат этого фильтра. Это одна из причин почему не стоит использовать множество фильтров в одном месте, нагружая лишней работой цикл $digest и одна из причин, почему новые фильтры работают быстрее. В новой версии фильтры ведут себя куда умнее и не вычисляют значение фильтра до тех пор, пока не изменится выражение к которому привязан данный фильтр.


Однако возникает проблема, как обновить значение фильтра, если оно зависит не только от выражения, но и от каких-то внешних факторов? Иными словами, как вернуть фильтру своё старое, "глупое" поведение, когда нам это нужно?


Для этого в 1.3 были введены понятия статичного (stateless) и динамического (stateful) фильтров.
По умолчанию фильтр ведёт себя как stateless. Сменить его поведение можно выставив нашему фильтру флаг $stateful в true.


Пример:


angular.module('myApp', [])
    .filter('customFilter', ['someService', function (someService) {
        function customFilter(input) {
            // манипуляция данными сторонним сервисом someService
            input += someService.getData();
            return input;
        }

        customFilter.$stateful = true;

        return customFilter;
    }]);

Breaking change:


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

Дополню от себя встреченными на практике перлами:

13. Используйте фильтры как хэндлеры при изменении дайджеста!

14. Изменяйте контекст всего $scope прямо внутри фильтра через this. Ваша версия ангуляра не даёт этого сделать? Прокидывайте контекст прямо внутрь через аргументы и изменяйте снова!
Насколько я понял, столы не покупаются, а берутся по контракту в аренду (что-то про "5$ per seat per day"), вот здесь есть калькулятор для ресторанов.
Я тоже готов присоединиться к кому-то, опыт ангуляра на продакшене три года, но в хакатонах ещё не участвовал :)

Странные кстати дни там выбраны
1

Information

Rating
Does not participate
Location
Чита, Забайкальский край, Россия
Date of birth
Registered
Activity