Как стать автором
Обновить
64
0
Дмитриев Сергей @antirek

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

Отправить сообщение
Еще недавно мы работали из офиса, и можно было спросить коллегу за соседним столом: «не помнишь, где работает приложение такое-то?» он называл имя сервера, и в целом ты быстро находил нужный сервер

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

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

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

но… чисто мне не очень нравится такой вариант, какое-то внутреннее убеждение, что можно как-то сделать более системно что ли. воспринимаю как временное решение, хотя людям стало удобнее искать где какие приложения работают, что в них входит, есть ссылка на описание работы приложения.
может быть автор еще что-то посоветует, я пока поделюсь своим опытом

у меня есть небольшая инсталяция: на нескольких машинах работает несколько приложений. Каждое приложение — это несколько докер-процессов, описанных в docker-compose.yml.

также в docker-compose.yml для каждого сервиса есть labels в которых есть дополнительная метаинформация, например, ссылка на документацию и url, который обслуживается этим сервисом (например, если там http-сервер)

все эти docker-compose.yml парсятся и создается html-табличка, где указано что за сервис, процесс и мета-информация из labels docker-контейнеров

парсинг происходит периодически и любой коллега имеет доступ к этой табличке и может посмотреть на какой машине какой сервис вертится. в этой инсталяции у меня работает порядка 200 контейнеров (не кубернетес же для этого городить ;), десятки поддоменов и т.д. поэтому табличка эпизодически напоминает где-что работает

при добавлении нового приложения и соответствующего ему docker-compose.yml парсинг его подхватит и табличка дополнится информацией

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

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

У меня была подобная задумка github.com/antirek/owo-phone.js

Про автообзвон тоже будет интересно.
Прикольная штука. И ведь не сильно сложно, особенно если еще и репозиторий глянуть )) почему репозиторий не прикладываете?

От статьи двоякое ощущение: что я вынес полезного? Какая проблема решена? Вовлечен ли я?

Записал несколько мыслей, как я бы это выразил:
1. типа есть проблема — кажется что надо делать навыки Алисы прямо вот детальными с беседой по заполнению списка и справкой, а если вы делаете MVP или для себя, то нет, не надо.

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

3. В application основная логика, константы (что за UC-1?? хз), переменные, (лес if-else конечно убивает, надо переписать ;)

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

5. сейчас модная тема — чеклисты, в инстаграмме чеклисты на всё — от правильной покраски бровей до подбора дома. если у вас бизнес по рекомендациям — типа помощь при покупке и подборе авто — вот вам навык Алисы для подбора — 10 пунктов, которые необходимо проверить в авто и итог, конечно, если все-таки сомневаетесь, звоните нам. И реализовать это — ну, прям два вечера и полторашка (поправьте меня если я ошибаюсь :))

6. Тем более что протестировать работу навыка вашим пользователям тоже вполне доступно — необязательно, сразу покупать Яндекс Станцию, можно и в Яндекс Браузере или установить Алису на смартфон или в песочнице сервиса.
www.around.co — интересный стартап видеоконференций, которые не занимают весь экран. Жду бету.
Текст набрали с вывихом руки? Без абзацев можно еще и вывих глаза получить )))
тут увидел проект github.com/Thomaash/me, сразу про ваши сети подумал ))
мое понятие network diagram шире )) все диаграммы вокруг не столько сетей, сколько вокруг сервисов, ПО, данных
у вас классный пример того, как можно документировать именно сети
Могу и про graphviz написать, т.к. рассматривал его до того как писать свой блекджек. Но если я где-то не прав — поправьте.
а) graphviz использует свою нотацию, которая достаточно мудрая, т.е. гибкая и местами сложная.
б) проект непонятно в каком состоянии — на сайте картинки не отображаются, доступ к доке на гитлабе закрыт. viz-js — веб-версия graphviz на гитхабе в рид-онли.
в) viz-js рекомендует использовать dagre.js
а вот dagre.js — интересная штука, хотя и не совсем то

у dagre.js интересный синтаксис
g.setNode("kspacey",    { label: "Kevin Spacey",  width: 144, height: 100 });
g.setEdge("kspacey",   "swilliams");

т.е. если бы не мое желание структуры, то можно было сделать подобное API

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

О, да, я его видел, забыл добавить в свой список )) Думаю, он вдохновил Raoul Meyer написать github.com/RaoulMeyer/diagram-as-code. К сожалению, он на python и более сервер-сайд решение.
а вы пользуетесь whatsapp через twilio?
Прикольно. Мог бы начать использовать, но нет проекта на php. Вот если бы вы делали как промежуточное звено со своим API (супер, если в openapi/swagger) да еще и в контейнере со всеми php версиями и зависимостями. Тогда использование вашего проекта как proxy-instagram-api очень привлекательно. Плюс безопасность: логин-пароль от инстаграм-аккаунта (в том числе корпоративного) лежит где-то в сервисе, а мои прочие сервисы просто по необходимости и постить могут или комментарии читать.

Хотя стоп, это уже было github.com/whizzzkid/instagram-proxy-api/issues/28
«Кто сдает продукт вторичный, тот снабжается отлично» (с) Москва 2042 В.Войнович
так это Иван Бегтин там размещает, расходимся ))
не хватает фотографий, Мирного, быта, окрестностей, там ведь наверняка красиво и местами технологично ))
А здесь нет унификации )) По мне пусть любой из вендоров сделает такую возможность, и я для его телефонов напишу приложения. И одеяло будет на его стороне.
По поводу проприетарности, тоже плавали-знаем, в итоге всем нашлась ниша и клиент — кто-то выбирает вендорные решения, а кто-то строит на астериске.

любой endpoint OpenAPI вы curl'ом легко проверите, в браузере все get'ы проверите, перешлете, обсудите, а SOAP, угу, wsdl-browser сначала найди норм

тут стандартная схема: будь проще и люди к тебе потянутся ))
Вы правы, похож. Но проще, и потому выбирают сначала OpenAPI, а не SOAP.
Первый абзац в разделе «Архитектура решения» рассказывает, что будет нелегко ))

Возможно, я не выразил ясно мысль в статье, но еще раз попробую: решений как сделать управление телефоном полно, может быть есть проще? например, через вебсокеты гонять json?

реализовать управление через tr-069 с cwmp да на soap я, пожалуй, смогу, но куча народу нет. а могли бы пилить свои программы на javascript'е и покупать телефоны в офисы и звонить, и кофеварками с жалюзями управлять.

а может и не надо чтоб было просто никому?

Информация

В рейтинге
5 329-й
Откуда
Красноярск, Красноярский край, Россия
Дата рождения
Зарегистрирован
Активность