Есть endpointA, endpointB, endpointC. Нужно ли для каждого endpoint’a делать свой entrypoint?
Т.е на endpoint’ах всё-равно доступ к API происходит на основании разрешений. Скажем, юзеры могут только обращаться к методу list, retrieve, а delete не могут делать. Какая принципиальная польза делать entrypoint, если внутрь него пробрасываются API из entrypoint’a?
В этом хуке some_create вызывает API endpointB. Допустим, endpointB лежит. Что делать? Нужно же куда-то записать эти данные, а потом, когда endpointB поднимется, сделать call API –> endpointB. Как правильно это организовывается? Чтобы я какой-нибудь велосипед не изобретал:)
При commit=600 при poweroff рабочая станция не выключается. В принципе удобно, 32гб озу, все пишется в оперативку. Раз в 10 минут скидывается на диск. Все эти 10 минут на диск ничего не пишется, диск постоянно не дёргается. Пробовал делать в скрипте выключения перед «shutdown -h now» sync - не помогает. Сейчас сделал commit=60 - вроде всё ок, но хотелось бы commit=600
Кстати, какие еще есть опции оптимальные для ext4?
У меня dwm со своими патчами и настройками. Я не знаю как лучше сделать. У dwm есть особенность - там после patch надо исправлять кое-какие строки. Делать чистые патчи и потом патчить настройки - не думаю, что это целесообразно. Итак, есть на битбакете полностью работоспособный dwm. Варианты:
тянуть с битбакета(нужен ssh ключ + пароль, который я не знаю(хранится в keepassx). При установке проблематично его будет доставать с keepassx
Формировать tar.gz и класть его внутрь конфигурации(правильно ли это?). Распаковывать и собирать
Какие еще есть варианты?
Если у кого-то есть примеры сборки своего dwm - если поделитесь будет круто:)
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
nothing to commit, working tree clean
git add .;git commit;git push origin master
Looking in links: /python-packages
test_upper (test_example.TestExample) ... ok
----------------------------------------------------------------------
Ran 1 test in 0.000s
OK
On branch master
Your branch is ahead of 'origin/master' by 1 commit.
(use "git push" to publish your local commits)
nothing to commit, working tree clean
Total 0 (delta 0), reused 0 (delta 0)
To bitbucket.org:some-name.git
5c5e62d..c463210 master -> master
В визуализации и на битбакет нет мерджа ветки в мастер
Есть модули, которые подключаются в .bashrc. Есть функции some-A, some-B,some-C,some-D, для их запуска нужна функция some-Z. Но функция some-Z появляется в автодополнении, к примеру:
class SomeTable(models.Model):
name = models.PositiveSmallIntegerField(
validators=[MinValueValidator(15), MaxValueValidator(250)],
verbose_name="some",
unique=True
)
Есть еще ctrl:swapcaps, который меняет местами ctrl и caps. А как сделать так, чтобы caps == ctrl, а сам ctrl отключить? Чтобы приучить себя 100% нажимать caps(как ctrl)?
Есть задача организовать отложенную запись данных(чтобы endpoint’ы не захлёбывались.
Как пример:
Есть chat-data, который имеет апи записи и чтения сообщений. Есть entrypoint chat, который предоставляет клиенту возможность писать другому пользователю сообщения и читать сообщения, которые адресованы этому пользователю.
Если писать и читать сообщения напрямую, есть несколько узких мест:
при большой нагрузке chat-data и chat могут захлёбываться
при отключении chat и\или chat-data сообщения не будут записаны в базу
Это просто пример, это касается всех действий пользователей, которые выполняют какие-то действия(события). Как это пофиксить? Скорей всего, необходим какой-то job-сервер, в который будут прилетать job’ы. Эндпоинт или entrypoint(?) подписывается на rabbitmq очередь, в которой он будет получать события «есть задача». Далее эндпоинт или энтрипоинт идет на job-сервер, блокирует записи, над которыми работает и начинает выполнять job’ы. Допустим в 8 потоков(настраиваемо должно быть). И выполняет их до тех пор, пока их не будет ноль. После выполнения - производится удаление job’ов.
Т.е получается, что chat chat-data могут быть отключены. При этом сообщения падают в job-сервер. Как только chat chat-data включаются, они заходят на job-сервер и начинают оттуда брать job’ы. Это правильно архитектурно? Или как-то по-другому надо делать?
Вопрос по job-серверу. Rabbitmq позволяет изменять messag’и? Т.е я делаю queue, туда прилетают job’ы. В отдельном queue прилетают нотификации о наличие job’ов. Эндпоинт или энтрипоинт выбирает несколько сообщений, блокирует их и начинает выполнять. По окончанию - удаляет их из queue. Rabbitmq позволит так делать? Или делать отдельный job-сервер с апи добавления задач и записи их, скажем, в postgresql?
Передняя часть у корпуса - сплошная сетка с фильтрами. Но у боковушки есть вентиляция и тянет воздух оттуда, где сопротивление потоку ниже т.е не с передней части, а с боковой крышки. Я вот думаю, может залепить скотчем вентиляционные отверстия на боковой крышке? Тогда воздух будет тянуть с торца передней части корпуса т.е через фильтры
Меньше пыли
Меньше шума от фана видеокарты и процессора
Прохладный воздух будет проходить через hdd, охлаждая его
Как думаете, стоит закрывать вентиляционные отверстия скотчем на боковой крышке?
PS: сейчас скотч на боковой крышке - резонансы крышки убрал
1. git clone --recurse-submodules -j8 git@bitbucket.org:some_name/some_data.git
2. cd some-data
ls -a common
. .. bash .git .gitignore python
cat common/.git
gitdir: ../.git/modules/common
cd common
touch 1; echo "wefwewwe" > 1
git add .;git commit;git push origin master
error: unable to push to unqualified destination: HEAD
The destination refspec neither matches an existing ref on the remote nor
begins with refs/, and we are unable to guess a prefix based on the source ref.
error: failed to push some refs to 'git@bitbucket.org:some_name/common.git'
cd ..
git add .;git commit;git push origin master
коммит проходит, но в репозитории common нет изменений, а в коммите some-data примерно такое: