Pull to refresh
4
0

Пользователь

Send message

websockets вообще не про экономию батарей. Все что будет сэкономлено на трафике, будет с успехом потеряно на поддержании соединения. При использовании http/2 валидных кейсов для ws очень мало (stateful сервер только, наверное) - разрабатывать это дело тоже сложнее.

В коммерческих проектах чаще всего не ООП непреложная данность, а фантазии на тему - типа папка Controllers и условные IOrderService. Так и сейчас от фп используют условные лямбды да вариации на тему Future 🤷‍♂️

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

да и многим «профессиональным» тоже не мешало бы прочитать…
в стримы можно писать.
1) субъективно легче использовать, больше функций из коробки, более легкая обработка слияний потоков (разные варианты — flatMap, switchMap, concatMap, предлагающие разные варианты на все случаи жизни)
2) сходное API в разных языках (ну и можно один и тот же код шарить между клиентом и сервером, например)
3) стримы как будто бы больше ориентированы на работу с потоками данных, всякие кодировки, буферы и т.д. Rx же — потоками событий/состояний системы (в качестве входного потока можно использовать например setInterval). Хорошо стакается, например, с Redux

Давайте на примере. У вас строка поиска, которая должна предлагать варианты автозаполнения, подгруженные с сервака. Наивная имплементация делается просто — при изменении строки делать запрос, возвращать результат через колбек/Promise/Task/что-там-awaitable-в-вашем-языке.
Теперь несколько моментов (допустим набираю habr):


  1. не хочется дергать запрос на каждый новую букву, нужен какой-то debounce (искать по habr, не по h,ha,hab,habr)
  2. не хочется дергать сервер совсем, если человек вбил букву, понял, что ошибся и удалил ее
  3. порядок выполнения — что если я делаю два запроса и второй выполняется до того как выполнился первый
  4. если хочется немного разгрузить сервис, можно добавить поддержку отмены запроса. Например, вбил 'h', запрос пошел, долго думает, вбил 'ha', abort первого запроса, второй запрос пошел, умный сервер может прибить первый запрос в базу и не отдавать ответ в никуда (CancellationToken в .NET).

Решение на Rx (в JS):


const stream =
  fromEvent(element, 'keyup').pipe(
    map(x => x.target.value),
    debounceTime(2000),
    distinctUntilChanged(),
    switchMap(x => ajax.get('http://service/term?q='+x)),
  )
.subscribe(console.log)

Я плохо знаком с питоном, можеть быть у вас там еще красивее это решается. Пример скорее про async/await в JS или .NET

теперь да, все ок :) когда я писал, использовался другой.
ой, а что с сертификатом по ссылке? :)
ну вот некая западная компания en.wikipedia.org/wiki/Futurice рекламировала себя на .NEXT, что у них, дескать, прозрачность и у всех сотрудников полный доступ ко всей финансовой информации. Чисто для примера, за достоверность и работоспособность не отвечаю :)
А это, насколько я понимаю, «фича» джавы — что любой метод, если не сказано обратное, виртуальный. В C# и C++ вот, например, не так, и ничего, живем.
синтаксис TS то не ужасен, это просто я криво выразился :) Ужасно различное количество доп. плясок вокруг всего этого для создания врапперов — http://docs.nativescript.org/plugins/ui-plugin

Все проблемы с документацией (вот код по линку в предыдущем абзаце — не работал) были пофиксены где-то в ноябре, спустя месяц как мы на него пожаловались. Нет, ну можно сказать что помогли :) Я не говорю, что этим невозможно пользоваться — я говорю о том, что при выборе стратегии мобильного девелопмента на длительное время вперед, это не то, что я лично готов выбрать или кому-то порекомендовать.

PS: Под ужасающим я имел в виду примерно ту кучу спама (в виде попапов, доп. окошек, доп. таргетов output'ов, которые почему-то на каждый перезапуск по дефолту выбираются и т.д.), которую он везде прокидывал.
Вот знаете, абсолютно нет ощущения, что NativeScript в самом расцвете, скорее на стадии отчаянной альфы. Рассматривали тут месяца два назад — проблемы с документацией (точнее примерами на гитхабе — не все даже компилируется/работает, а Telerik и не в курсе). Проблемы с количеством существующих компонентов (ну вот карт, например, не было). Можно да, написать свою собственную обертку. И над iOS, и над Android. Ужасным синтаксисом. Только вот не вижу тут тогда никакой выгоды.
Как результат, сделали вывод — Todo-list приложения писать можно :) А еще, как еще один результат, пришлось чуть-чуть пожить с ужасающим аддоном к VS и кучей спама от Телерика.
я всего лишь привел предмет юз-кейса комментатору выше. Да и условный «заказчик» может быть вполне себе внутренним, не обязательно аутсорс.
Заказчик может вспомнить, что у него есть команда, и захотеть узнать на что конкретно был потрачен этот месяц, по часам. И т.д.
о, ComponentSpace, поделие крисумрачных гениев… требование наличия сессии (причем есть класс типа InMemoryStorage, который!!! все-равно зависит на модуль сессии потому что SessionId с базового класса у них на него зависит), привязка намертво к HttpContext, отсутсвие поддержки Owin, чего еще бы вспомнить — в общем, надеюсь, что откажемся скоро… — пока написан кастомный HttpModule, в котором вся логика работы.
PS: вам бы тоже не рекоммендовал заигрываться с фасадами и HttpContext'ами, не тестируемо же, да и на конкретный synchronization context завязываетесь.
а в случае гитхаба-репо как пакета можно указывать версию / range версий пакета? тэг/ветку-то вроде можно, а вот диапазон?
из документации сложилось впечатление, что @a/b бесплатен, но кто угодно может @a/c создать, а так можно и права на @a раздавать, как на чтение, так и на запись. Сам не пробовал — у нас просто свой собственный registry. Гитхаб это все-таки немножко не то — разница, например, в версионности.

Information

Rating
Does not participate
Works in
Date of birth
Registered
Activity