Почему бы не добавить для юзеров ссылку — продолжить работу с сайтом ${window.location.host} + таймер секунд на 10 для автоперехода — там ставить coockie что юзер уже видел заглушку и больше ему ее не показывать.
А по-моему все отлично! И спасибо вам за ряд ссылок(а по этим ссылка еще ссылки, в общем очень познавательно) =)
Хорошая, «добрая» статья и всё «по полочкам». Приятно было почитать, медленно, вникая, переходя по всем ссылкам.
Что касается самой тематики, моё мнение(и кто-то кстати сказал это до меня) — дело не в IT и не в этой всей сфере, дело в людях — кто-то счаслив, в своем браке например или как-то иначе в своей жизни, а кто-то нет, и они, местами, особенности своей жизни, приписывают отрасли в которой работают. У кого-то «все плохо» у кого-то наоборот «миллион возможностей», у кого-то «средненько». Думаю это напрямую связано с самими личностями.
То есть люди просто переносят свой жизненный опыт на сферу в которой работают.
Мне за 3 месяца(раз в неделю по скайпу) помог по сути случайный психолог, на авито нашел, выбирал тупо по фото )
Дело в том, что ваша ситуация с большой вероятностью — типовая. Вспоминается вот это «ты не снежинка» — куча людей с типовыми проблемами и есть типовые методы их решения. То есть ничего такого уж особенного специализированного не требуется.
«Ребята зарабатывают бабки, выгодно ли им лечить?» — почему-то человек так устроен что да. Про системных администраторов и программистов то же можно сказать — если бы все работало их бы уволили. Но тем не менее все стремятся писать системы которые работают без их поддержки и не создают специально баги чтобы потом их править и обеспечивать себя тем самым работой на будущее.
Попробовал, классно, спасибо!
Но docker-image все же не удобен для использования в CI.
То есть вот у меня приложение билдится как раз в CI(то есть уже docker-in-docker) и вашу тулзу туда никак не вписать
CI docker image
FROM node:10-alpine as builder
COPY ./prod ./site_sources
WORKDIR /site_sources
RUN npm i
RUN npm run build
Можно еще просто генерировать юзеру eth аккаунт прямо в браузере тут даже соединение с интернетом не требуется для регистрации и авторизации ) gitlab.com/kellas/p2p/tree/master/Auth/public
Можно еще хранить данные в indexedDB, т.к. к ней есть доступ из service-worker, как обертка идеально подходит Dexie.
Записывать действия юзера не сразу в БД, а в виде «тасков» на отправку, при наличии соединения отсылать их на сервер.
Он не будет жечь. Потому что он внутри тела. Кольцо на пальце например сильно нагревается снаружи и начинает обжигать кожу. Чтобы метка под кожей получила столько же тепла, оно сначала должно пройти через кожу(то есть хорошо так обжечь), типа того.
Организм внутри себя поддерживает нормальную температуру, пирсинг на языке например не жжет(если с открытым ртом не сидеть все время). Можете попробовать в сауне кольцо под язык положить и самостоятельно в этом убедиться.
Почему-то про сервис-воркеры пишут только в контексте кэша и работы оффлайн.
Использую для выполнения фоновых операций, +push уведомления юзерам о статусе этих операций и возможном прекращении их выполнения(если видно что закрыты все вкладки).
Как результат например общая для всех вкладок область видимости/«глобальная асинхронность», то есть если юзер открыл сервис в нескольких вкладках он не может запустить занового идентичный процесс, т.к. этот процесс идет в едином сервис-воркере.
Блин, страшно обновляться, как там с поддержкой плагинов и обратной совместимостью?
Если новый GUI — значит тема слетит? А что на счёт остальных пользовательских настроек, плагинов итп?
Не существует у нас в глазах «колбочки» воспринимающий жёлтый, мозг решает, что что-то жёлтое если цвет между красным и зелёным, отсюда я делаю вывод, что жёлтый — это неопределённость или компромисс, когда мы точно не можем определить на глаз красный/оранжевый либо зелёный/салатовый.
Т.е.мой посыл такой: Если наш глаз не может однозначно идентифицировать жёлтый, можно ли в таком случае однозначно называть какой-то цвет жёлтым ориентируясь только на своё зрение, без специального оборудования?
Пишу нечто похоже по архитектуре.
Использую gunjs + leveldb. Gun поднимает веб-сокет на бакенде и клиент к нему подключается. Этот подход понравился тем что можно без труда перенести приложение в веб, т.к. там не юзается ipc и вообще ничего что как-то может зависеть от electron. Т.е. у меня сейчас оно так и билдится, есть билд для веб, клиент + сервер, есть всё вместе внутри electron.
Почему бы не добавить для юзеров ссылку —
продолжить работу с сайтом ${window.location.host}+ таймер секунд на 10 для автоперехода — там ставить coockie что юзер уже видел заглушку и больше ему ее не показывать.И можно не ограничиваться 30 минутами .
Хорошая, «добрая» статья и всё «по полочкам». Приятно было почитать, медленно, вникая, переходя по всем ссылкам.
Что касается самой тематики, моё мнение(и кто-то кстати сказал это до меня) — дело не в IT и не в этой всей сфере, дело в людях — кто-то счаслив, в своем браке например или как-то иначе в своей жизни, а кто-то нет, и они, местами, особенности своей жизни, приписывают отрасли в которой работают. У кого-то «все плохо» у кого-то наоборот «миллион возможностей», у кого-то «средненько». Думаю это напрямую связано с самими личностями.
То есть люди просто переносят свой жизненный опыт на сферу в которой работают.
Дело в том, что ваша ситуация с большой вероятностью — типовая. Вспоминается вот это «ты не снежинка» — куча людей с типовыми проблемами и есть типовые методы их решения. То есть ничего такого уж особенного специализированного не требуется.
«Ребята зарабатывают бабки, выгодно ли им лечить?» — почему-то человек так устроен что да. Про системных администраторов и программистов то же можно сказать — если бы все работало их бы уволили. Но тем не менее все стремятся писать системы которые работают без их поддержки и не создают специально баги чтобы потом их править и обеспечивать себя тем самым работой на будущее.
Но docker-image все же не удобен для использования в CI.
То есть вот у меня приложение билдится как раз в CI(то есть уже docker-in-docker) и вашу тулзу туда никак не вписать
FROM node:10-alpine as builder
COPY ./prod ./site_sources
WORKDIR /site_sources
RUN npm i
RUN npm run build
FROM nginx:1.15.8-alpine
ADD ./nginx.conf /etc/nginx/conf.d/default.conf
WORKDIR /var/www
COPY --from=builder /site_sources/dist .
...
поэтому cli утилита была бы предпочтительнее, чтобы можно было сделать что-то типа
npx shakal ./distпример публикации пакета github.com/alexstep/universal-analytics/blob/master/.github/workflows/npmpublish.yml
Такой подход сработает посланной с загрузкой фото или видео?
gitlab.com/kellas/p2p/tree/master/Auth/public
Лучше один раз попробовать с одним каким-нибудь занятием.
"Цели" они гибкие и плавающие.
Записывать действия юзера не сразу в БД, а в виде «тасков» на отправку, при наличии соединения отсылать их на сервер.
Организм внутри себя поддерживает нормальную температуру, пирсинг на языке например не жжет(если с открытым ртом не сидеть все время). Можете попробовать в сауне кольцо под язык положить и самостоятельно в этом убедиться.
Использую для выполнения фоновых операций, +push уведомления юзерам о статусе этих операций и возможном прекращении их выполнения(если видно что закрыты все вкладки).
Как результат например общая для всех вкладок область видимости/«глобальная асинхронность», то есть если юзер открыл сервис в нескольких вкладках он не может запустить занового идентичный процесс, т.к. этот процесс идет в едином сервис-воркере.
Если новый GUI — значит тема слетит? А что на счёт остальных пользовательских настроек, плагинов итп?
Т.е.мой посыл такой: Если наш глаз не может однозначно идентифицировать жёлтый, можно ли в таком случае однозначно называть какой-то цвет жёлтым ориентируясь только на своё зрение, без специального оборудования?
Использую gunjs + leveldb. Gun поднимает веб-сокет на бакенде и клиент к нему подключается. Этот подход понравился тем что можно без труда перенести приложение в веб, т.к. там не юзается ipc и вообще ничего что как-то может зависеть от electron. Т.е. у меня сейчас оно так и билдится, есть билд для веб, клиент + сервер, есть всё вместе внутри electron.