Тут стоит добавить, что качество работы тоже изменилось:
Раньше: тут делаем основу, остальное в тех.долг или на другом приложении через год доделаем, у нас сроки!
Сейчас: делаем это все, заодно перелопатим старый тех.долг, чтобы это все наконец нормально работать начало. И позовем тут эксперта, пусть подскажет, а то м ыдо такого уровня еще не доходили.
Да, часы те же и больше, но внутри этих часов совсем другое содержимое должно быть.
Ну тут ответ банальный: работаем вокруг 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 раз. И по каждому разу надо было вытащить с них отдельную справку, что они вот теперь стали другим юр.лицом. А советский человек макулатуру складывал исправно, было попроще, чем тут в статье описывают.
А так как в царстве-государстве у нас те же самые советские люди, которые любят бумажки, то лучше иметь пачку макулатуры до "последнего момента", чтобы не услышать классическое "в какой отделении карту открывали..".