никто не делил админов на dba, devops и сетевых да ?

По сути да. делается по принцыпу лонг поллинг

Там ничего общего с Лонг поллинг

Там ничего общего с Лонг поллинг

я понял уже, спасибо)

никто не делил админов на dba, devops и сетевых да ?

dba тоже можно к админам отнести?

причем эти dba как миниму 2-3 штуки. oracle, mssql, postgresql

ааа

ну еще nosql

а так да

тупиковая ветвь развития

dba тоже можно к админам отнести?

ты не повери что последняя буква означает

архитектор

не угадал

афтар

та ладно))

data base architector

data base admin это вообще что

https://ru.wikipedia.org/wiki/DBA

data base admin это вообще что

Тот кто следит за БД, бьет по рукам нерадивых разрабов, пишет процедуры и помогает составлять запросы

а еще есть debian, redhat

там свои приколы

Тот кто следит за БД, бьет по рукам нерадивых разрабов, пишет процедуры и помогает составлять запросы

и миграции прогоняет

и миграции прогоняет

> Следит за БД

а мы админы нихера не делаем

да

whats the most lightware nodejs db?

Как поменять кодировку ??

�������

приходит такая херь вместо кириллицы

whats the most lightware nodejs db?

sqlite3

приходит такая херь вместо кириллицы

в телеграмме?

в телеграмме?

нет у меня

Как в строке поменять коировку

Как в строке поменять коировку

node-iconv

node-iconv

спасибо

node-iconv это нативный метод или его надо подключать*?

node-iconv это нативный метод или его надо подключать*?

http://lmgtfy.com/?q=node-iconv

Подскажите, кто нибудь сталкивался с задачей организации темы wp по аналогии с проектами frontendа? Сборка гальпом и организация папок Scr, Public и т.д?

У тебя SPA будет и много жаваскрипта ?

У меня начальство, которое хочет именно так и не иначе

Однако. Ну идея то конечно здравая. Но если там жаваскрипта на одну только галерею...

Подскажите, кто нибудь сталкивался с задачей организации темы wp по аналогии с проектами frontendа? Сборка гальпом и организация папок Scr, Public и т.д?

а какие проблемы с этим? и gulp и webpack могут собирать произвольный контент

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

А в sequelize есть es7 синтаксис или хотя бы классы?

Вроде обсуждали в 4 версии или лучше делать как по старинке

В документации не нашел этого

или bookshelfjs?

А когда sequelize успел стать интерпретатором?

ват

есть кластер из node stateless серверов в докер контейнерах, нужно добавить daily tasks, какое решение по рекомендуете?

есть кластер из node stateless серверов в докер контейнерах, нужно добавить daily tasks, какое решение по рекомендуете?

Запускать скрипты с помощью крона

тогда все сервера буду выполнять одну и туже задачу, а надо чтобы она выполнилась только один раз

т.к докер образ у всех одинаковый

тогда все сервера буду выполнять одну и туже задачу, а надо чтобы она выполнилась только один раз

А кто говорил в образы добавлять еще один процесс?

т.к докер образ у всех одинаковый

Делаешь либо образ, из которого запускаешь контейнер раз в день, либо контейнер с кроном и скриптом внутри

Можно все хранить в одном образе, просто оверрайдить CMD у образа

т.е как отдельный сервис?

т.е как отдельный сервис?

Да У тебя docker swarm?

нет AWS eb но примерно суть та же

нет AWS eb но примерно суть та же

Да, помню Разве что с k8s не знаком

нет AWS eb но примерно суть та же

По мне так оверрайдить команду- самый оптимальный вариант. Плодить еще один образ- я погорячился

при этом куча логики по таскам завязанна на самих серверах, надо добавлять вебхук, чтобы этот сервис стучался на сервер чтобы выполнить таск?

не варик переносить эту логику на другой сервис

не варик переносить эту логику на другой сервис

Так тебе нужно по крону задачу выполнять, либо по событию?

Так тебе нужно по крону задачу выполнять, либо по событию?

по крону

но задача комплексная

и там уже написанна куча кода для нее

и там уже написанна куча кода для нее

То есть у тебя часть архитектуры вне swarm?

при этом куча логики по таскам завязанна на самих серверах, надо добавлять вебхук, чтобы этот сервис стучался на сервер чтобы выполнить таск?

очередь задач. отложенная задача

кроны в целом 'нинужны'

они плохо ложатся на докер

они плохо ложатся на докер

Но это же оверхед для этой задачи, не?

если есть сущность "комментарий", который может относиться к двум разных сущностям, то лучше сделать две сущности "комментарий"?

То есть у тебя часть архитектуры вне swarm?

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

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

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

Да блин, просто создаешь скрипт внутри приложения, а дальше в компоуз файле cmd переопределяешь и все

если есть сущность "комментарий", который может относиться к двум разных сущностям, то лучше сделать две сущности "комментарий"?

а структура данных у них разная? или только привязка разная?

CMD ["node", "src/scripts/dothemagic.js"]

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

а если кто-то дернет хук N раз? а если упадет сервер при выполнении задачи?

вылазит вопрос управляющей ноды, которая дергате кроны?

а структура данных у них разная? или только привязка разная?

только привязка разная, а структура одинаковая

а если кто-то дернет хук N раз? а если упадет сервер при выполнении задачи?

с кроном разве не будет таких проблем?

Но это же оверхед для этой задачи, не?

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

я тоже склоняюсь к очереди

с кроном разве не будет таких проблем?

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

не придется писать все это самому, потому что это не задача твоего проекта

только привязка разная, а структура одинаковая

тогда на мой взгляд лучше сделать enumeration entity_type

тогда на мой взгляд лучше сделать enumeration entity_type

аха, хорошо. Тогда получается comment(id, text, author_id, entity_type, ref_id) ?

аха, хорошо. Тогда получается comment(id, text, author_id, entity_type, ref_id) ?

ну да, только тип надо жестко ограничить перечислением

ну да, только тип надо жестко ограничить перечислением

спасибо