Ну тут ответ банальный: работаем вокруг composer, который собрал все связанное зависимостями. Так устроен мир.
У бизнеса логика простая: с кого мы будем спрашивать за последствия? Надо прикрыть себя. Потому надо было свое.
А почему не сделать форк? Нам же не нужно вообще все от тех сервисов, а они развивают какую-то свою концепцию, которую мы можем не быстро раскурить. Создавая свое, мы понимаем, что именно заложено, какие идеи можно держать в голове и соломку подстелить на будущее, но на первой стадии не перегружать продукт, решить текущие задачи.
У маленьких студий есть одно важное преимущество — талатливые люди в коллективе! И по мере работы с продуктом, ресурса достаточно. А вот когда на нас свалятся тысячи установок и баг-репортов, то тут уже и расширяться начнем, решать эти новые проблемы.
Ну и просто приятно, что мы первые сделали такой продукт в РФ и засунули в Реестр Минцифры. Кто-то что-то невероятное пилит, а мы сделали одну прикольную штуку, которая решает прикладную задачу.
Классический подход, с которого все начинают. Уверен, что у вас все четко работает.
У нас ситуация была и есть гораздо сложнее: скрипты связаны друг сдругом и вариант "смотреть файл" уже не подходит, слишком много файлов, управление нужно не из консоли, а менее квалифицированным человеком и из браузера.
Если не секрет, расскажите, что ваши скрипты делают для маркетплейсов?
HealthChecks как раз первый в списке, но он observer, а надо было побольше всего.
Второй сервис тоже был, но он тоже про анализ падения, а нам на старте надо было увязать задания друг за дружкой. Алерт успешного выполнения мы уже проходили простым сообщением, человек ручками запускал следующий скрипт. А надо вебхук дернуть, хотя бы.
RunDeck посмотрел сейчас, кажется мощным оркестратором сложных интеграций, который в том числе решает вопросы с cron'ом. В первом приближении кажется, что он так же будет тяжелым для решения узкой задачи.
Бережное отношение к загрузке сервера (CPU, RAM) стояло у нас в критериях высоко. Забыл об этом упомянуть в статье.
Ну и досадный момент — опенсорс нам зарубили в какой-то момент волевым решением, пришлось решать вопросы привычным методом.
Тут сложнее, ваши кейсы могут быть сложнее, чем мой совет ниже.
В нашем случае стараемся делить задачи на такие блоки, которые можно "дернуть ручкой" на предыдущий этап. То есть, задание проверяет входные данные и может выйти на рекурсию на Х шагов назад. Разумеется, что число таких шагов тоже надо считать и разбирать каждый случай.
Сначала думали, что удалено, но, как потом сказала поддержка, облако просто выключилось. За это и начали бороться дальше, чтобы получить последнее, что там было и запустить в целом.
Завели на учетку облако и прекрасно несколько лет работали. Никто не смотрит на эту учетку как нечто божественное, ну показывается там ФИО и почта, и ок. Удобно.
Удалил ящик в списке ящиков в Коннекте. Но почта же есть, она не удалена. И вы так же в списке видите этот ящик, переключаетесь, заводите счета, админите сервер. Все логично, так и должно быть, мы же не удаляли ничего на Я.Облаке.
Но через несколько дней щелкает у Облака, что баланс изменился, просят оплатить, а через 3 минуты грохают аккаунт и нет вашего облака, нет в списке адресов этого адреса. Нет никаких id-шниклв, коими весь аккаут облака усеян, есть только старые счета и акты, их которых можно вытащить разное про контракт. И тишина.
Условный "Вася" в вашей терминологии воспринимает все по ходу пьесы нормально, так и должно было быть. А почему пропал ящик и все остальное дальше — становится понятно через пару часов переписки.
Про SSH-доступы мы давно переросли, тут вопросов нет. А что все облако уходит по непредсказуемой причине — к такому ранее готовы не были. Вот теперь мы и про это знаем.
Возможно, что для погруженных в тему это кажется банальным и логичным, что по каждому ящику админ пройдет по всей пачке сервисов и за пару дней трудозатрат на обсуждение с командой поймет, что там ценного, а что нет.
В моем случае все иначе, я воспринимал учетку как пару ЛОГИН:ПАРОЛЬ и не думал о чем-то ином. Для меня это просто учетка, и не важно где лежит домен, важно, что это логин и пароль доступа к Личному кабинету. Домен же у меня, почта на него приходит на другом сервисе, все в порядке. Но оказалось, что все сильно сложнее. Под этим впечатлением написан пост, потому что найдутся те, кто воспринимает сервис с доменами ровно так же и могут не понимать до конца, во что они ввязываются, работая с учетками экосистемы.
Когда выводил отца на пенсию, оказалось, что любая бумажка из СССР и 90-х очень пригождались в начислении годов стажа. В том числе оказалось, что завод, на котором он работал, был обанкрочен к этому моменту уже 14 раз. И по каждому разу надо было вытащить с них отдельную справку, что они вот теперь стали другим юр.лицом. А советский человек макулатуру складывал исправно, было попроще, чем тут в статье описывают.
А так как в царстве-государстве у нас те же самые советские люди, которые любят бумажки, то лучше иметь пачку макулатуры до "последнего момента", чтобы не услышать классическое "в какой отделении карту открывали..".
Ну тут ответ банальный: работаем вокруг composer, который собрал все связанное зависимостями. Так устроен мир.
У бизнеса логика простая: с кого мы будем спрашивать за последствия? Надо прикрыть себя. Потому надо было свое.
А почему не сделать форк? Нам же не нужно вообще все от тех сервисов, а они развивают какую-то свою концепцию, которую мы можем не быстро раскурить. Создавая свое, мы понимаем, что именно заложено, какие идеи можно держать в голове и соломку подстелить на будущее, но на первой стадии не перегружать продукт, решить текущие задачи.
У маленьких студий есть одно важное преимущество — талатливые люди в коллективе! И по мере работы с продуктом, ресурса достаточно. А вот когда на нас свалятся тысячи установок и баг-репортов, то тут уже и расширяться начнем, решать эти новые проблемы.
Ну и просто приятно, что мы первые сделали такой продукт в РФ и засунули в Реестр Минцифры. Кто-то что-то невероятное пилит, а мы сделали одну прикольную штуку, которая решает прикладную задачу.
Классический подход, с которого все начинают. Уверен, что у вас все четко работает.
У нас ситуация была и есть гораздо сложнее: скрипты связаны друг сдругом и вариант "смотреть файл" уже не подходит, слишком много файлов, управление нужно не из консоли, а менее квалифицированным человеком и из браузера.
Если не секрет, расскажите, что ваши скрипты делают для маркетплейсов?
Драматургия пострадает, надо же "завязка -> кульминация -> развязка" чтить еще =)
HealthChecks как раз первый в списке, но он observer, а надо было побольше всего.
Второй сервис тоже был, но он тоже про анализ падения, а нам на старте надо было увязать задания друг за дружкой. Алерт успешного выполнения мы уже проходили простым сообщением, человек ручками запускал следующий скрипт. А надо вебхук дернуть, хотя бы.
RunDeck посмотрел сейчас, кажется мощным оркестратором сложных интеграций, который в том числе решает вопросы с cron'ом. В первом приближении кажется, что он так же будет тяжелым для решения узкой задачи.
Бережное отношение к загрузке сервера (CPU, RAM) стояло у нас в критериях высоко. Забыл об этом упомянуть в статье.
Ну и досадный момент — опенсорс нам зарубили в какой-то момент волевым решением, пришлось решать вопросы привычным методом.
Тут сложнее, ваши кейсы могут быть сложнее, чем мой совет ниже.
В нашем случае стараемся делить задачи на такие блоки, которые можно "дернуть ручкой" на предыдущий этап. То есть, задание проверяет входные данные и может выйти на рекурсию на Х шагов назад. Разумеется, что число таких шагов тоже надо считать и разбирать каждый случай.
Спасибо за поддержку =)
Сначала думали, что удалено, но, как потом сказала поддержка, облако просто выключилось. За это и начали бороться дальше, чтобы получить последнее, что там было и запустить в целом.
Было вот как.
Завели на учетку облако и прекрасно несколько лет работали. Никто не смотрит на эту учетку как нечто божественное, ну показывается там ФИО и почта, и ок. Удобно.
Удалил ящик в списке ящиков в Коннекте. Но почта же есть, она не удалена. И вы так же в списке видите этот ящик, переключаетесь, заводите счета, админите сервер. Все логично, так и должно быть, мы же не удаляли ничего на Я.Облаке.
Но через несколько дней щелкает у Облака, что баланс изменился, просят оплатить, а через 3 минуты грохают аккаунт и нет вашего облака, нет в списке адресов этого адреса. Нет никаких id-шниклв, коими весь аккаут облака усеян, есть только старые счета и акты, их которых можно вытащить разное про контракт. И тишина.
Условный "Вася" в вашей терминологии воспринимает все по ходу пьесы нормально, так и должно было быть. А почему пропал ящик и все остальное дальше — становится понятно через пару часов переписки.
Про SSH-доступы мы давно переросли, тут вопросов нет. А что все облако уходит по непредсказуемой причине — к такому ранее готовы не были. Вот теперь мы и про это знаем.
Возможно, что для погруженных в тему это кажется банальным и логичным, что по каждому ящику админ пройдет по всей пачке сервисов и за пару дней трудозатрат на обсуждение с командой поймет, что там ценного, а что нет.
В моем случае все иначе, я воспринимал учетку как пару ЛОГИН:ПАРОЛЬ и не думал о чем-то ином. Для меня это просто учетка, и не важно где лежит домен, важно, что это логин и пароль доступа к Личному кабинету. Домен же у меня, почта на него приходит на другом сервисе, все в порядке. Но оказалось, что все сильно сложнее. Под этим впечатлением написан пост, потому что найдутся те, кто воспринимает сервис с доменами ровно так же и могут не понимать до конца, во что они ввязываются, работая с учетками экосистемы.
Освобождение от налога на прибыль будет в следующем году за 2022, а за 2021 надо заплатить, как положено.
Сегодня появилась информация "Отправлено на перенос", посмотрим, как пойдет.
Долго бился, чтобы все получилось, в итоге пишет "Перенесено", вот только нигде у меня этих перенесенных материалов нет.
У кого получилось, вы нашли материалы в своем профайле?
А не заметили ли вы в коде/методах возможности управлять дисплеем? Чтобы туда что-то свое выводить?
Поддержка отнекивается который год, хотя, казалось бы, ничего хитрого не должно быть.
Спасибо, теперь концепция понятна!
Ага, а бывает, что число issues будет больше или меньше, чем в Планфиксе? Или задача в Планфиксе скорее как branch в Гитлабе - пачка задач для трека?
Артем, отлично сделали!
Подскажите, пару вопросов:
Из Гитлаба у вас прилетает Label от Issues и кладется в строку или как сделали?
И где инициируете Issues: в Планфиксе или на стороне Гитлаба? Как ПФ узнает, какая задача чему в Гитлабе соответствует?
Трек времени тоже из Гитлаба тянете по /spend или ребята время трекаются в двух системах?
Когда выводил отца на пенсию, оказалось, что любая бумажка из СССР и 90-х очень пригождались в начислении годов стажа. В том числе оказалось, что завод, на котором он работал, был обанкрочен к этому моменту уже 14 раз. И по каждому разу надо было вытащить с них отдельную справку, что они вот теперь стали другим юр.лицом. А советский человек макулатуру складывал исправно, было попроще, чем тут в статье описывают.
А так как в царстве-государстве у нас те же самые советские люди, которые любят бумажки, то лучше иметь пачку макулатуры до "последнего момента", чтобы не услышать классическое "в какой отделении карту открывали..".