Задать вопрос
  • Можно ли транслировать видео с локальной камеры в RTSP используя только браузер?

    @hbruser
    Браузеры поддерживают всего два "протокола" по которым можно транслировать видео с локальной web-камеры (если мы говорим про камеру, которую использует браузер):
    - WebRTC
    - RTMP и ему подобные

    1. Показывать видео с камеры компьютера в окне браузера практически чистым HTML5


    Чистый HTML5 - это:
    - Canvas + Websockets.
    - WebRTC video element
    - HLS тоже можно назвать самым чистым

    2. Проигрывать видеопоток в браузере через WebRTC и видеть его с другого IP адреса через VLC player

    VLC умеет играть RTSP.

    Сервер, который умеет все что вы описали одновременно, это Web Call Server 4.
    - принять поток по WebRTC
    - раздать по HTML5 Websockets
    - раздать по WebRTC
    - раздать по RTSP

    Вообще говоря если задержка не критична, лучше использовать HLS (Apple HTTP Streaming).
    Все остальные протоколы доставки не являются кроссбраузерными или имеют другие ограничения.
    Ответ написан
    Комментировать
  • Как деплоить небольшие проекты?

    @Stqs
    senior software developer
    вопросы у вас философские, на каждый можно отвести часы обсуждения
    Полноценный CI/CD поднимать не вижу смысла ввиду размеров

    вы ж все равно собираетесь какие-то скрипты мутить и чото выдумывать,
    какая разница это будут крон скрипты на сервере или джоба в дженкинсе? по-скорости написания - одно и тоже будет. так что по-моему размер тут не имеет значение
    единственное что имеет значение - насколько явно у вас описан процесс(алгоритм) билда/разворачивания приложений
    с этой точки зрения мое видение примерно такое:

    1) git не есть инструмент для развертывания по, git лишь для версионирования кода
    и по-идее результатом вашей работы должен быть не код в гитхабе, а какой-то вменяемый артефакт, готовый к деплою (docker-image, pip пакет, npm пакет, deb пакет, jar, war, zip в крайнем случае, и тд и тп). Если производить артефакты то вопрос с тегами отпадет сам собой - у вас будет артефакт какой-то версии и все
    сервер не должен знать ни про какие гиты и ни про какие-то теги в нем
    Здесь я бы рекомендовал паковать все в докер-имеджи хотя бы только потому, что сервер в итоге не будет знать ничего о зависимостях приложения, нужных библиотеках, ниочем вообще, вам нужно установить только докер
    Огромное преимущество использование докера - в Dockerfile вы вынуждены волей/неволей описать точно и явно все шаги требуемые для установки приложения. И что самое замечательное - это все будет храниться в том же репозитории, под контролем гит - шикарно.
    Артефакты желательно хранить в каком-то артефактории,
    но если реально все просто - то можно хранить несколько последних версий прямо на сервере в какой-нибудь папочке

    2) как только вы получили артефакт - его можно деплоить
    неплохо было б знать особенности вашего проекта, но грубо говоря допустим что достаточно его зааплоадить на сервер, положить в нужное место
    опять же с этим дженкинс справится на ура и займет у вас это все дело 10 минут . Если вы опишете логику в Jenkinsfile вы выиграете еще раз потому что процесс развертывания(алгоритм) будет описан опять же ЯВНО. И будет тоже под контролем гита. (Jenkins должен знать только в каком репозитарии и в каком месте ему искать Jenkinsfile)
    Если же вы будете крутить какой-то спрятанный cron скрипт на сервере - о нем никому ничего не будет известно. Поверьте уже через короткое время все это дело начнет усложнятся, что-то забудется, что-то измениться и это все вместе больно ударит вас по яйцам.

    В чем еще преимущество такого подхода: если вам нужно сделать roll-back на предыдущую версию вам не нужно собирать проект заново выкачивая все с гита, ведь у вас есть предыдущие артефакты, ролбек в таком случае вообще не проблема - просто указываем предыдущую версию артефакта и деплоим еще раз и все

    3) Env Variables
    когда приложение стартует - считывает все что ему нужно из переменных окружения
    деплой джоба может каждый раз эти переменные устанавливать перед тем как деплоить - это было бы тоже круто потому что вы сделали бы это знание так же явным

    Итого имеем
    - логика сборки проекта описана в Dockerfile и находится под гитом
    - логика деплоя находится в Jenkinsfile и находится под гитом, и что самое главное является кодом (Jenkinsfile пишем на груви, для простых вещей вам понадобиться 30 минут изучения и все)
    - на сервере мы ничего не устанавливали совершенно кроме самого докера
    - мы храним несколько версий нашего приложения на всякий случай и можем быстро откатиться не прибегая к гиту вообще
    - сервер не знает ничего о гитах
    - на сервере нет НИКАКОЙ дополнительной логики по разворачиванию вашего приложения
    - имея все это очень легко добавлять другие сервера для деплоя - что нам нужно - грубо говоря указать другой айпи и набор env variables к нему ( если они конечно отличаются)
    giphy.gif
    Ответ написан
    5 комментариев
  • Как деплоить небольшие проекты?

    copist
    @copist
    Empower people to give
    1. Хорошая ли идея стягивать все исключительно по тегам т.е. поставил я на фронте и на беке тег v0.4 и скрипт на сервере стянул и то и другое
    2. Самонаписанный скрипт постоянно чекающий теги гитлаба это вообще идея хорошая? В чем +\- деплоя по тегам?


    Метки ставить можно. Даже полезно релизы метками отмечать. Всегда можно определить, на какой комит надо откатиться, чтобы локально восстановить версию кода как на сервере. И release notice писать по git log между метками, а не в памяти держать.

    Постоянно чекать git не надо. Лишняя нагрузка на проц. Совершенно лишняя. Рекомендую веб-хуки или деплоить по SSH команде.

    3. Как быть с адресами и портами.

    Выносите в конфигурационные файлы или в параметры окружения

    10+ вариантов на странице https://css-tricks.com/deployment/
    Я для разного размера проектов пользовался
    1. deployhq - как только обновляется ветка master - сервис обновляет сервер по SSH
    2. веб-хуками из bitbacket + самописным веб-скриптом на PHP без таймлимита - как только приходит хук об обновлении ветки master, выполняется скрипт типа такого
    cd /var/www/project
    cp web/closed.bak web/closed.html # закрыть приложение
    git pull
    composer update && php yii migrate # как то код бэка обновить
    npm run build # как то код фронта обновить
    rm web/closed.html # открыть приложение

    3. такой же командой, запускаемой через ssh, без веб-хуков. Это когда понадобилось сразу бэк и фронт пересобирать из разных репо и из разных веток. Ну типа демо из ветки develop, а релизы из ветки master на несколько серверов.
    4. настраивали Jenkins для авто-установки

    В принципе устраивает
    Ответ написан
    2 комментария
  • Чем конкретно занимается Frontender сейчас?

    "То фронт это только получение АПИ и его вывод + верстка?" Если в общем, то ДА.
    Если подробнее, то:
    Не во всех компаниях фронты занимаются версткой. Сварганить SPA тоже надо уметь, особенно когда нужно асинхронно в реалтайме обновлять информацию. Плюс всякие локальные задачи: валидация данных; оптимизация размера бандла; потихоньку пришел PWA со своими плюшками (webworkers, пуши, кэш и прочее); работа с API тоже может быть разной (JSON REST, вебсокеты, graphql); Тестирование кода на стороне клиента (приемочные тесты); Трекинг действий пользователя; Различные интерактивные игры (webgl); и прочее...
    Область достаточно большая, если копать глубоко.
    Ответ написан
    Комментировать
  • Полноценный пример SSR для react/redux?

    Да состояние собирается на сервере для каждого клиента (request'a), скажем на уровне мидлвара мы собираем состояние (текущего авторизованного пользователя, какие-то другие глобальные данные), далее отрабатывает обработчик маршрута, мы получили данные какой-то страницы из бд и передали их как контекст, примерно так:
    import React from 'react';
    import { StaticRouter } from 'react-router'
    import { Provider } from 'react-redux'
    import ReactDOMServer from 'react-dom/server';
    
    import App from './client/components/App.jsx'
    
    ReactDOMServer.renderToString(
    	<Provider store={ReduxStore}>
    		<StaticRouter
    			location={Url}
    			context={Context}>
    			<App/>
    		</StaticRouter>
    	</Provider>
    );

    Где, ReduxStore сгенерированное нами глобальное состояние (redux) запроса, Url запрошенный урл, Context контекст (будет передано как this.props.staticContext в компонент). Реакт вытянет нужный контейнер роута (по вашим маршрутам в App) и передаст ему контекст, компонент рендерится исходя из полученных данных. Результатом работы метода renderToString будет html строка (размеченная реактом), которую мы шаблонизатором или как угодно впиливаем в блок моунта компонента (в верстке), дополнительно в шаблонизатор передаем сгенерированное состояние, в документации выглядит вот так:
    window.__PRELOADED_STATE__ = JSON.stringify(preloadedState || {}).replace(/</g, '\\u003c')

    Теперь что происходит после того как страница загрузилась и подхватились клиент-скрипты? Все просто мы подхватываем состояние из window.__PRELOADED_STATE__ и вообщем-то все, глобальное состояние передано, компонент уже отрендерен, стоит учитывать что результаты при клиент-рендере и при сервер-рендере должны быть всегда одинаковыми, так же не использовать методы доступные браузеру, но не доступные серверу (на уровне моунта и первого рендера) и хорошенько следить за своим кодом в плане памяти, иначе при какой-либо утечке, память на сервере не будет вычищаться после каждого рендера.
    ---
    Как-то так, надеюсь помог, хотя там еще довольно много заковык
    Ответ написан
    20 комментариев
  • Законно ли хранение пользовательских данных в firebase Google?

    inoise
    @inoise
    Solution Architect, AWS Certified, Serverless
    13 секунд на поиск ответа.

    GCP не имеет хранилищ на территории России (в рамках Firebase как минимум)
    Ответ написан
    1 комментарий
  • Законно ли хранение пользовательских данных в firebase Google?

    dimonchik2013
    @dimonchik2013
    non progredi est regredi
    Ответ написан
    Комментировать
  • Что такое aria и role атрибуты?

    @senselessV7
    ...
    Допустим, при взаимодействии с насыщенным интернет-приложением (в терминологии ARIA такие приложения именуются активными) пользователь не просматривает страницу, а прослушивает ее с использованием экранного диктора. При этом программа зачитывает вслух одну часть страницы, а тем временем другая ее часть динамически обновляется. Живые области ARIA подсказывают пользователю, что обновилась часть страницы — та, которая в данный момент находится не в фокусе ...

    ...
    Существуют атрибуты состояния ariadisabled, aria-busy, aria-expanded, aria-hidden и атрибуты свойств, в частности ariadescribedby, aria-haspopup и aria-labelledby, предоставляющие дополнительную информацию о переопределенных элементах. На практике рекомендуется макси-
    мально полагаться на семантические элементы, но если вам непременно требуется использовать конкретный элемент (допустим, древовидное меню) «не по назначению» — прибегайте к ARIA-атрибутам. ...


    Эстель Вейл "Разработка приложений для мобильных устройств"
    Глава 6


    Почитайте, вполне интересно и полезно!
    Ответ написан
    1 комментарий
  • Стоит ли переходить на React.PureComponent по-умолчанию?

    PQR
    @PQR
    React.PureComponent реализует метод shouldComponentUpdate таким образом, что он делает поверхностное сравнение props и state (не глубокое). Вот собственно код:
    https://github.com/facebook/react/blob/c8fbdac2271...
    shouldUpdate =
                !shallowEqual(prevProps, nextProps) ||
                !shallowEqual(inst.state, nextState);


    Что такое shallowEqual? Это по сути сравнение оператором === каждого элемента из prevProps с каждым элементом из nextProps. На всякий случай дам ссылку на реализацию для полного понимания: https://github.com/facebook/react/blob/6963ea4bfcd...

    В итоге всё зависит от структуры ваших props. Если в props вы передаёте объекты которые иногда мутируются, т.е. по ссылке они равны ===, но внутри какие-то данные поменялись (что само по себе выглядит странно в экосистеме redux + reselect, но вполне возможно технически), тогда использование PureComponent вам всё поломает, т.к. на экране какие-то компоненты перестанут перересовываться!

    Если же у вас всё по уму, данные которые передаются через props являются скалярными типами (string, int, float, bool) или immutable объектами, тогда смело используйте PureComponent - в некоторых случаях он поможет избавиться от лишних вызовов render.

    Важное замечание: PureComponent нужно использовать только для так называемых presentational components, т.е. для тех компонент, которые НЕ обёрнуты в вызов redux connect().

    Для container components (т.е. тех компонент, которые обёрнуты в redux connect()) нет смысла наследоваться от PureComponent, т.к. метод connect() оборачивает ваш компонент своей реализацией shouldComponentUpdate, которая также использует shallowEqual. Если вы по недосмотру унаследуете container component от PureComponent - ошибок не будет, но это не имеет никакого смыла, т.к. ваш код по сути будет дважды делать shallowEqual, а зачем делать лишнюю работу?

    Подводя итог, рецепт такой:
    - presentational components наследуем от React.PureComponent
    - container components (которые обёрнуты в redux connect()) наследуем от старого доброго React.Component
    Ответ написан
    1 комментарий
  • Meteor.js расцветает или чахнет?

    PQR
    @PQR
    Не согласен с предыдущим оратором (@geeek), в частности с утверждением
    В общем если хочешь быть в тренде - бери
    - Meteor совсем не в тренде.

    Если дать краткий и резкий ответ на вопрос "расцветает или чахнет?" - отвечу: интерес к Meteor чахнет, не смотря на все усилия команды разработки.

    Компания MDG (Meteor Development Group) подняла $31M инвестиций (https://www.crunchbase.com/organization/meteor) и хотела всё сделать круто, стать мейнстримом, а потом зарабатывать на хостинге Meteor проектов - такой план монетизации. Хостинг они, кстати, сделали. И в какой-то момент было много хайпа вокруг Meteor, казалось, что всё идёт по плану. Полтора года назад вышел Meteor 1.0 (октябрь 2014), потом была пара хороших релизов, которые убрали всю "сырость": Meteor 1.1 и 1.2.

    Но в середине 2015 стало понятно, что никаким мейнстримом они не стали, мейнстрим нынче React!
    Не смотря на простоту старта и скорость разработки с Meteor, были очевидны следующие минусы:

    1. Собственная система пакетов со своим центральным репозиторием https://atmospherejs.com - посмотрите на счётчики скачивания пакетов, это крохи по сравнению с npm. Посмотрите на активность разработки основных пакетов - всё очень тухленько.

    2. Собственная система сборки. С одной стороны всё работает из коробки, с другой стороны в неё не вклинишься (это сложно). Плюс всякие странные условности, что всё в глобальном пространстве имён и ваши js файлы загружаются в алфавитном порядке. В Meteor 1.3 частично решили проблему, ходят слухи, что в будущем будут использовать webpack.

    3. Собственный шаблонизатор blaze (похож на handlebars). В начале blaze выглядел хорошо, но теперь все внезапно пишут на React и многие потирают руки в ожидании Angular 2, в итоге blaze оказался ещё один велосипедом, с которым не понятно что делать.

    4. На бекенде всё ещё Node 0.10. Даже с Node 0.12 Meteor уже не работает из-за некоторых бинарных зависимостей! Обещали в будущих версиях обновиться с поддержкой Node 4.

    5. Метеор сильно завязан на MongoDb. Чтобы реактивно доставлять новые/изменившиеся данные от сервера в бразуер они парсят логи Mongo. Были попытки сделать аналогичное для SQL баз, но не увенчались успехом. В итоге встречайте их новый проект Apollo, который поверх GraphQL и не привязан к конкретной реализации бекенда www.apollostack.com А что теперь будет со старым добрым DDP?

    6. Ваше Meteor приложение одной командой можно упаковать в мобильное приложение Cordova - выглядит круто, но сейчас время ReactNative и вот мы читаем обсуждения на форумах, что возможно, они таки интегрируются с ReactNative, но когда?

    Подводя итог: ребята из MDG подняли кучу денег и хотели сделать всё сами: свои пакеты, свою сборку, свой шаблонизатор, свой реактивный протокол (DDP) и чтобы всё работало из коробки. И они сделали это!

    Только это оказалось никому не нужно, т.к. для пакетов все сидят на npm, сборка должна быть гибкой (и поэтому у нас есть gulp и webpack), самый модный шаблонизатор нынче - это React, реактивный протокол GraphQL и базы на сервере люди любят разные, а не только MongoDb. А Meteor, по сути, остался на обочине всей экосистемы и движухи вокруг JavaScript. Поняв это, MDG начали двигаться в сторону JS комьюнити и первый шаг сделан: Meteor 1.3 поддерживает нормальные модули ES2015, npm пакеты, рендринг через React и Angular. Но Meteor 1.3 - это куча костылей поверх старого велосипедного Meteor. Почитайте их планы на будущее в официальном блоге, хотя бы в этом посте: info.meteor.com/blog/announcing-meteor-1.3 - им по сути предстоит переписать всё заново! И первые ласточки такого "переписывания" - это выделение проекта Apollo.

    Возможно, со второй попытки они всё сделают правильно и Meteor 2.0 действительно выстрелит. Если только у них деньги не закончатся раньше.

    Сейчас можно взять Meteor и эффективно зарабатывать на маленьких/средних фриланс проектах, когда нужно сделать быстро и не думать о долгосрочной поддержке.
    Если же вы делаете большой продукт, то вас ждут большие потрясения и изменения в экосистеме Meteor.
    Ответ написан
    4 комментария
  • Это вообще люди делают?

    dimovich85
    @dimovich85 Куратор тега CSS
    https://u-academy.net/
    Поделюсь с вами вот такой ссылкой:
    https://www.youtube.com/playlist?list=PLswdBLT9llb...
    Ответ написан
    1 комментарий