Как разработка, конечно, такое себе. Но! Как проект… как идея… Вы его видели? Это ж бомба просто. Форчан и двач отдыхают. Кравч. Кравч. Кравч! Вы только в слушайтесь в название. Как можно придумать такое название проекта?
и новости, и чат на одной странице — что-то есть в этом. канал аниме — это типичная имиджборда с элементами дискорда (типа список участников колонкой справа). еще и рисовач есть, как в теплом ламповом ВК, когда еще на стене рисовать можно было.
регистрация просто отстой, переусложнена. но автор в предыдущей статье рассказывает, что она ему очень нравится. и вообще всюду сквозит сельский снобизм автора — эти дрочеры, эти анонимусы, зачем обертки к бд? думаю, это молодость, автору всего 27 — для разработчика это всё еще время становления и экспериментов #сарказм
конечно, не хватает аудитории. причем какой-то такой «своей». ну, т.е. постоянных анимешников или спортклуба какого-то, которые бы общались и мемасились каждый вечер, но это, вероятно, автор задрот сам где-то зависает, идею запилил, а аудиторию не перетащить так просто с насиженной площадки.
код — это просто сплошной «вот так вот не надо», сейчас в тиктоке много видео с этой мелодией, по этому коду в любое место ткни, сними видео и в рекомендованное тиктока зайдешь на ура!
в итоге,
1. автору спасибо, от самих статей куча положительных эмоций (разбирать на мемы-стереотипы про программистов из техана, цитаты из статьи на футболках печатать можно, это прямо хабрастендап какой-то, в комментариях живое юморное общение, автор из образа не выходит — огонь!)
2. идея норм, жаль что не в текущей реализации не взлетит, т.к. автор не подсадит кого-то на регулярное использование кравча (но про это как раз и есть эта статья, не так ли?)
Аналогично смутило сравнение нишевых вещей типа haxe и какой-то hyoo-ru/mam-mol с популярными продуктами ))
а вот для сравнения между собой angular/react/vue — весьма интересно наблюдение, не более
А можно пример необходимости команды на удаление задач из вне? Т.е. по идее можно в task положить данные по актуальности задачи и на уровне исполнения при наступлении времени отсеять как более не актуальную, не так ли?
Чем не устраивает просто писать consumer'ов для rabbitmq queue? с установленным delayed message plugin, например? это если в сторону простоты
а если в сторону универсальности, то delayed task это часть workflow, например в рамках BPMN. И соответственно, вероятно, проще весь workflow выполнять на каком-то движке, не выделяя отдельно delayed task. Пробовали ли какой-то workflow engine (https://github.com/meirwah/awesome-workflow-engines) для решения своей задачи по отложенным рассылкам?
В банковском приложении Телекард 2.0 (версия 1.1.52) Газпромбанка нет чата поддержки. П-ф-ф… ну и как тут обычному банкингу не победить? Если пришлось идти писать заявление по подключенной дополнительной услуге в отделение банка )))
Вот все хорошо, начнешь пользоваться, напишешь систему, запустишь ее, будет работать год, а то и два, а потом решишь добавить что-то или обновить, а вы бах и забросили её уже и домен не продлили, и нет больше ни проекта, ни документации, переписывай на новом фреймворке. почему не делаете сайт и доку на github pages? тем более у вас на jekyll вроде генерится все
для кого статья? явно же не для всех «любителей хабр» ))
сделай удобно
если для программистов php: оформи под composer и выложи код на гитхаб
если для желающих скачивать тиктоки: сделай страничку с полем и кнопкой «скачать»
Еще недавно мы работали из офиса, и можно было спросить коллегу за соседним столом: «не помнишь, где работает приложение такое-то?» он называл имя сервера, и в целом ты быстро находил нужный сервер
сейчас каждый в своем домашнем офисе работает, и звонить чтобы спросить как-то не всегда удобно, поэтому html-табличка появилась. по логам глянул — ежедневно коллеги на нее заходят по нескольку раз.
сначала это просто была таблица: машина — приложение — сервис. сейчас стал понемногу добавлять обслуживаемые url и ссылки на документацию (в том числе на swagger-интерфейсы), и стали чаще спрашивать когда добавлю оставшиеся ))
так как докер еще логи через сислог на машину логов скидывает, где логи также лежат в директориях соответствующих машинам, то понятно где логи разыскивать. поэтому субъективно — данными пользуются каждый день.
но… чисто мне не очень нравится такой вариант, какое-то внутреннее убеждение, что можно как-то сделать более системно что ли. воспринимаю как временное решение, хотя людям стало удобнее искать где какие приложения работают, что в них входит, есть ссылка на описание работы приложения.
может быть автор еще что-то посоветует, я пока поделюсь своим опытом
у меня есть небольшая инсталяция: на нескольких машинах работает несколько приложений. Каждое приложение — это несколько докер-процессов, описанных в docker-compose.yml.
также в docker-compose.yml для каждого сервиса есть labels в которых есть дополнительная метаинформация, например, ссылка на документацию и url, который обслуживается этим сервисом (например, если там http-сервер)
все эти docker-compose.yml парсятся и создается html-табличка, где указано что за сервис, процесс и мета-информация из labels docker-контейнеров
парсинг происходит периодически и любой коллега имеет доступ к этой табличке и может посмотреть на какой машине какой сервис вертится. в этой инсталяции у меня работает порядка 200 контейнеров (не кубернетес же для этого городить ;), десятки поддоменов и т.д. поэтому табличка эпизодически напоминает где-что работает
при добавлении нового приложения и соответствующего ему docker-compose.yml парсинг его подхватит и табличка дополнится информацией
но это такой промежуточный наколенный вариант, возможно у кого-то есть что-то получше, буду рад узнать
Прикольная штука. И ведь не сильно сложно, особенно если еще и репозиторий глянуть )) почему репозиторий не прикладываете?
От статьи двоякое ощущение: что я вынес полезного? Какая проблема решена? Вовлечен ли я?
Записал несколько мыслей, как я бы это выразил:
1. типа есть проблема — кажется что надо делать навыки Алисы прямо вот детальными с беседой по заполнению списка и справкой, а если вы делаете MVP или для себя, то нет, не надо.
2. Вот мой пример: список что-кого сделать при уборке, закоммитил список, сделал сценарий беседы по списку — легко? вполне. вы хотите такое? да? отлично, вот мой репо смотрите как сделал я.
3. В application основная логика, константы (что за UC-1?? хз), переменные, (лес if-else конечно убивает, надо переписать ;)
4. какие списки могут быть? покупки, конечно. бытовые — в гипермаркете сходить раз в неделю затариться. и ваши профессиональные чеклисты — порядок уборки, подготовки документа, список приложений на смартфон и т.д.
5. сейчас модная тема — чеклисты, в инстаграмме чеклисты на всё — от правильной покраски бровей до подбора дома. если у вас бизнес по рекомендациям — типа помощь при покупке и подборе авто — вот вам навык Алисы для подбора — 10 пунктов, которые необходимо проверить в авто и итог, конечно, если все-таки сомневаетесь, звоните нам. И реализовать это — ну, прям два вечера и полторашка (поправьте меня если я ошибаюсь :))
6. Тем более что протестировать работу навыка вашим пользователям тоже вполне доступно — необязательно, сразу покупать Яндекс Станцию, можно и в Яндекс Браузере или установить Алису на смартфон или в песочнице сервиса.
и новости, и чат на одной странице — что-то есть в этом. канал аниме — это типичная имиджборда с элементами дискорда (типа список участников колонкой справа). еще и рисовач есть, как в теплом ламповом ВК, когда еще на стене рисовать можно было.
регистрация просто отстой, переусложнена. но автор в предыдущей статье рассказывает, что она ему очень нравится. и вообще всюду сквозит сельский снобизм автора — эти дрочеры, эти анонимусы, зачем обертки к бд? думаю, это молодость, автору всего 27 — для разработчика это всё еще время становления и экспериментов #сарказм
конечно, не хватает аудитории. причем какой-то такой «своей». ну, т.е. постоянных анимешников или спортклуба какого-то, которые бы общались и мемасились каждый вечер, но это, вероятно, автор задрот сам где-то зависает, идею запилил, а аудиторию не перетащить так просто с насиженной площадки.
код — это просто сплошной «вот так вот не надо», сейчас в тиктоке много видео с этой мелодией, по этому коду в любое место ткни, сними видео и в рекомендованное тиктока зайдешь на ура!
в итоге,
1. автору спасибо, от самих статей куча положительных эмоций (разбирать на мемы-стереотипы про программистов из техана, цитаты из статьи на футболках печатать можно, это прямо хабрастендап какой-то, в комментариях живое юморное общение, автор из образа не выходит — огонь!)
2. идея норм, жаль что не в текущей реализации не взлетит, т.к. автор не подсадит кого-то на регулярное использование кравча (но про это как раз и есть эта статья, не так ли?)
а вот для сравнения между собой angular/react/vue — весьма интересно наблюдение, не более
А можно пример необходимости команды на удаление задач из вне? Т.е. по идее можно в task положить данные по актуальности задачи и на уровне исполнения при наступлении времени отсеять как более не актуальную, не так ли?
а если в сторону универсальности, то delayed task это часть workflow, например в рамках BPMN. И соответственно, вероятно, проще весь workflow выполнять на каком-то движке, не выделяя отдельно delayed task. Пробовали ли какой-то workflow engine (https://github.com/meirwah/awesome-workflow-engines) для решения своей задачи по отложенным рассылкам?
Может и понятней. с async agi как бы одна точка подключения, а так получается две. но с другой стороны — все одно звонок в agi заводить.
а еще с корутинами вопрос: т.е. для каждого вызова работает своя корутина? если в ней происходит ошибка, то как идет работа с другими звонками?
сделай удобно
если для программистов php: оформи под composer и выложи код на гитхаб
если для желающих скачивать тиктоки: сделай страничку с полем и кнопкой «скачать»
сейчас каждый в своем домашнем офисе работает, и звонить чтобы спросить как-то не всегда удобно, поэтому 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. Тем более что протестировать работу навыка вашим пользователям тоже вполне доступно — необязательно, сразу покупать Яндекс Станцию, можно и в Яндекс Браузере или установить Алису на смартфон или в песочнице сервиса.