Как успехи? Если у вас радиаторы, то термоголовки решают проблемы, если теплый пол, то смесительный узел со своей термоголовкой на обратке или вообще с моторчиком, которым уже управлять автоматикой
Не стоит пытаться поддерживать температуру в доме с помощью самого котла, если только это не всего одна комната с одной системой отопления
В конце статьи приведен итоговый конфиг, который правильно настроен и который все и копируют к себе, потому что зачем искать, куда что вставить/поменять, если все уже готово. И тут для многих кмк и возникает проблема, почему дальше ничего не работает - в конфиге внешний интерфейс указан ваш "eth3" ))) Я это нашел только когда начал пытаться по методу Анонима сделать установку и искать по его инструкциям в правилах iptables, а что там в итоге вышло. А вышло eth3, а не ppp0, который у меня ))) Надо бы там жырным и красным до/после примера конфига указать, чтобы люди меняли имя интерфейса
Да, у меня ваши настройки не заработали для телика LG и для андроида (для компа пошло), а вот на настройках Анонима все норм. Искать пока не стал, в чем там разница
О, я таки нашел, как люди обходят дебильное решение Кайтен по привязке карточек к доскам, а не к пространствам. Хотя что мешало сделать по человечески, непонятно - трава и желание выделиться видимо, а теперь для того, чтобы одну и ту же задачу можно было гонять по разным отделам/исполнителям, нужно создавать к ней "подзадачи" и настраивать костыли в виде маршрутизаторов, чтобы задача упала в нужную доску. Я уж не говорю про то, что если человеку не повезло и он должен видеть и обрабатывать задачи из разных досок, то он должен разместить и видеть все эти 100500 досок у себя в пространстве... Это пипец. Как на это можно перейти из Жиры??? ))))
+‑ с июня 2022г. в 8 раз выросло количество обращений на импортозамещение этих сервисов в EvaTeam.
Был 1 а стало 8?
Мы в EvaTeam полгода закрывали разрыв по функциональности с Jira и Confluence.
К декабрю 2022 закрыли разрыв (осталось улучшить популярные плагины типа «structure») + сделали крутой импорт.
Возможность крутить шурупы отверткой а не шуриком тоже можно считать за "закрытие разрыва в функционале". Но какое-то оно сомнительное
Основной болью на декабрь 2022г. оставался интерфейс (по словам клиентов). Он был немного другой, пользователи не хотели привыкать. Было принято стратегическое решение — сделать полный клон. Вариант интерфейса «Jira».
Жаль, что нам так и не удалось заслушать начальника транспортного цеха увидеть в статье примеры интерфейса, который будет... или есть... или что... или когда...????
Ниже описание со скриншотами того, что удалось разработать за полгода. Российские разработчики сделали за полгода то, что разрабатывалось и внедрялось 20 лет (первый релиз Jira 2002г.).
Не смешите рынок, а то потенциальные покупатели помрут со смеху - кому продавать будете? ))))
====
Я конечно понимаю, что хочется со всех сил пропиарить свой продукт, но... Нельзя же уж совсем так.
Когда ты слышишь слова "мы сделали клон жиры" и т.д. и потом реально заходишь в этот "клон", то ... ощущения не передать словами: толи плакать хочется, толи смеяться, толи еще чего...
Очень уж "клон" похож на студенческую поделку с основным лозунгом разработки "пофиг как, но чтоб было хоть как-нибудь и быстро". И самое главное - после этого еще с год-два я не пойду смотреть на это изделие, даже если вы выпустите еще сотню статей "мы уже все переделали, у нас прям все ваще ваххх как". Отличная антиреклама.
Я подозреваю, что Space делала отдельная команда, которая была не в курсе разработок YouTrack и TeamCity — ну по крайней мере технически.
Или Space делали для… эээ, а для кого? Неужели свои собственные разработчики не пользовались своими собственными YouTrack и TeamCity? Такое разве может быть?
А если пользовались — и как они теперь живут, бедные, в трех системах? Или в одной, но урезанной, но зато с коммуникациями?
Не одна версия по уму не может быть правдивой, но как ни крути, а версия должна быть
JetBrains, мы вас теряем? :))
Тот же вопрос и тоже «слегка» озадачен: создан универсальный инструмент для совместной работы cо всем и вся, но почему-то с «демо-версией» работы с задачами, больше никак тут не назвать существующий механизм Issues в Space. И это при существовании нормального YouTrack.
Возникает сразу вопрос: почему не впихнули одно в другое? Ну как так? Или над Space (как обычно) работали совсем другие люди и про YouTrack были «не в курсе», а потом уже было поздно? )))
В итоге то проблема так и не решена:
* есть отдельный инструмент Space для коммуникаций и документации, с расширенной информацией по командам и т.д., в общем, неплохая вещь — ну когда будут готовы процессы для бизнес-подразделений (code-review для документов и т.д.). Да, для разрабов все есть, кроме одного: нет нормального функционала задач. И как они живут? Или подразумевается, что все разрабы, вот все десятки и сотни разрабов (а в будущем и обычных пользователей), настолько дисциплинированы и адекватны, что без ошибок будут делать всю работу и ни разу не пихнут задачу не в тот статус? Роботы? ))
* и есть отдельный инструмент YouTrack для работы над задачами — с воркфлоу и т.д., который частично пересекается по функционалу. Ну а если его сконнектить со Slack, то будут и коммуникации более-менее
И для того, чтобы иметь и тот и тот функционал, пользователи будут все-равно работать в разных системах
Хотя решение объединения систем напрашивается само собой — и тогда бы с чистой душой можно было и использовать и предлагать такой продукт для любой потребности, какая возникнет у компании: хочешь задачи — на, хочешь коммуникации — на, хочешь ci/cd/git/code review — бери, хочешь команды — пожалуйста, хочешь это все вместе — да без проблем
Ыыыыыыыыыы
Не всем получится жрать кактус — многие его не смогут даже попробовать
Ну например возьмем пример, когда есть AD, коннект к внешним СУБД и все воркфлоу обвешаны скриптами — и тут облако не светит. Уж не говоря про требования ФЗ и СБ
ДЦ при 10000 пользователей тоже не светит — там цена невменяемая
Хошь не хошь, а такому клиенту за 3 года надо найти, куда свалить
Мы видим очередное подтверждение теории «чем дальше в лес больше денег, тем меньше остается мозгов»
Атлассиан решили дальше строить свою жизнь исключительно с домохозяйками — а кто еще может работать в облаке? Это же мучительные мучения — взять только одну асинхронную модель, не говоря уж про кучу всего другого, чему нет никаких аналогов в облаке
Честно говоря, не представляю, как крупный клиент с жирной жирой может уйти в облако — это просто невозможно, хоть даже бесплатно оно будет
ДЦ — с ценой, которая озвучена, проще свою жиру написать
Обчим, жира гудбай, атлассиан гудбай, видимо так
Надо искать что-то другое
Не, оно конечно, если вдруг от атласианов начнут валить — ну или сообщать, что свалят — большие и жирные клиенты, оно может и вправит мозги, но что-то я не уверен: если люди решили, что они умеют летать и начали разбег к обрыву, то их уже не остановить
Я добавлю более явно, что нужно еще уметь использовать мультитул
Не нужно его прижимать со всей дури, это действует как раз в обратную сторону — ничего не пилится
Хотя по опыту конечно же мы думаем, что чем сильнее держать и прижимать, тем лучше
Вот тут мультитул отличается от всех остальных — его надо держать очень нежно :), практически чтобы он давил своим весом, ну типа того.
Все это оттого, что он работает через вибрацию насадки относительно материала, а если его сильно прижать, то таких вибраций уже не будет — будут вибрации всего мультитула относительно насадки и материала.
Поэтому у начинающих (как у меня) бывает, что «нифига оно не работает, выкинуть его да и все»
Однако стоит только держать его правильно — и все становится хорошо
Как только работать им научишься — то и сразу проблем нет, зачем и как его использовать
Но таки да, он очень специфический инструмент
И лучше кстати брать его проводным, а не аккумуляторным, потому что аккума очень уж на мало хватает, жрет он быстро их
Но железо и даже алюминь я бы им не пилил — лучше ножовкой по металлу, руками, чем им
Вот дерево/пластик и т.д. — самое то
А, понял, про что вы. :)
Нет, не пойдет: JQL используется только для выборки списка заявок по параметрам. К служебным данным он отношения не имеет
И боюсь API не сможет выдать данные по параметрам настройки конкретного экрана на портале сервисдеска
Т.е. данные по заявке то я могу получить разными способами, но вот как называется конкретное поле на конкретном экране конкретного портала — я думаю что только через sql. Может конечно и еще как-то, но мне sql ближе — на нем все быстрее, понятнее и можно добраться до всех данных, какие есть в бд
И кстати, ScriptRunner становится платным — причем очень платным для количества лицензий начиная от 250 (http://www.adaptavist.com/w/continuing-to-develop-scriptrunner-for-jira/). Дешевле купить все плагины JJUPIN и т.д. от кеплера
Если у вас один тип запросов и всегда один набор полей, то да, сойдет, как альтернатива создания запроса напрямую через Жиру
Ну да, он умеет создавать от указанного пользователя, это хорошо.
Правда я не смог заставить его работать нормально — статистику использования он не показывал
Но если у вас много типов запросов, много категорий, от которых зависит набор полей, если нужны расширенные комментарии к полям и вообще другие названия для них в зависимости от типа и категории — тут только JSD
Он вовремя подоспел — мы перевели всю техподдержку у себя на Жиру
Разработка до этого перешла, через Жиру
Вообще в Жире очень низкий порог вхождения нового пользователя, который ни разу ее не видел и вообще ни с чем таким не работал
Он практически нулевой
Но через email нельзя заполнить никакие поля, кроме описания и темы
А если брать явное создание запросов пользователем, то в Жире можно указать все, что надо (выпадающие списки, даты и т.п.)
JSD дает более удобную работу с этим всем — человек вообще может даже и не знать, как на самом деле выглядит заявка в Жире, подавая заявки через JSD
Так по почте и т.д. — это все сама Жира
А Service Desk — это удобная настраиваемая морда для подачи заявок и удобная их обработка: SLA + очереди + отчеты
Настроить можно без проблем, если что-то уже приходилось настраивать в Жире
Есть уже плагин, добавляющий некоторые плюшки к JSD, которых там нет и руки до них у Атлассиана вряд ли быстро дойдут
Но это шире, чем просто Service Desk
Или вообще — это не Service Desk :)
Ну в понимании этого термина, как Служба Поддержки пользователей, реагирующая на их запросы
ServiceDesk, если прямо переводить — служба поддержки.
Кого и как вы ей поддерживаете — ваше личное дело, никакие итили и т.д. тут никому не могут ничего указывать
Что есть служба поддержки?
Это заявка пользователя и работы по ней., т.е. простейший баг-трекер. А если обработка не в стиле «принял — обработал — закрыл», то это уже совсем не простейший баг-трекер, а нормальный процесс
Касаемо Жиры
У нас на ней сделан и SD, и процесс разработки, и процессы между отделами компании, и т.д.
А JIRA Service Desk вообще очень сильно продвинул Жиру в смысле приема заявок от пользователей
Я потихоньку пишу краткую статью про JIRA Service Desk (JSD), там информация будет о нем, возможно вам поможет.
Надеюсь за недельку закончить
По поводу применимости
Проблема JSD в том, что пользователь должен залогиниться в систему, чтобы написать через JSD заявку
Если у вас все пользователи видят Жиру и нет проблем с количеством лицензий — то смело можно использовать. Если один из этих пунктов в пролете — то остается только по письмам создавать задания от единого универсального пользователя
Если исходить из того, что у нас все хорошо с дисциплиной, то остается только процессы сделать нормальными — а тут поможет и этот набор средств, и любой другой, лишь бы в них уметь работать
Может стоит лучше расписать, чем поможет именно данный инструмент и как с ним работать, чтобы он помог.
Хотя я боюсь, что обычно все наоборот: и процессы есть (вроде), и средств полно — а толку нет, потому что нет дисциплины. И это самое сложное. После процессов.
Кстати, ко всем средствам я бы добавил очень важное требование — легкое изменение под требования процессов. Мы пока поставили процессы, раза три их меняли, а вместе с ними и процессы трекера. Но он позволяет это делать относительно быстро и просто. А если нет? :)
Как успехи? Если у вас радиаторы, то термоголовки решают проблемы, если теплый пол, то смесительный узел со своей термоголовкой на обратке или вообще с моторчиком, которым уже управлять автоматикой
Не стоит пытаться поддерживать температуру в доме с помощью самого котла, если только это не всего одна комната с одной системой отопления
термоголовка на каждый радиатор решает же эти проблемы
В конце статьи приведен итоговый конфиг, который правильно настроен и который все и копируют к себе, потому что зачем искать, куда что вставить/поменять, если все уже готово. И тут для многих кмк и возникает проблема, почему дальше ничего не работает - в конфиге внешний интерфейс указан ваш "eth3" ))) Я это нашел только когда начал пытаться по методу Анонима сделать установку и искать по его инструкциям в правилах iptables, а что там в итоге вышло. А вышло eth3, а не ppp0, который у меня ))) Надо бы там жырным и красным до/после примера конфига указать, чтобы люди меняли имя интерфейса
Да, у меня ваши настройки не заработали для телика LG и для андроида (для компа пошло), а вот на настройках Анонима все норм. Искать пока не стал, в чем там разница
>>доска маршрутизатор
О, я таки нашел, как люди обходят дебильное решение Кайтен по привязке карточек к доскам, а не к пространствам. Хотя что мешало сделать по человечески, непонятно - трава и желание выделиться видимо, а теперь для того, чтобы одну и ту же задачу можно было гонять по разным отделам/исполнителям, нужно создавать к ней "подзадачи" и настраивать костыли в виде маршрутизаторов, чтобы задача упала в нужную доску. Я уж не говорю про то, что если человеку не повезло и он должен видеть и обрабатывать задачи из разных досок, то он должен разместить и видеть все эти 100500 досок у себя в пространстве... Это пипец. Как на это можно перейти из Жиры??? ))))
Эммммм... ну ладно, по порядку ;)
+‑ с июня 2022г. в 8 раз выросло количество обращений на импортозамещение этих сервисов в EvaTeam.
Был 1 а стало 8?
Мы в EvaTeam полгода закрывали разрыв по функциональности с Jira и Confluence.
К декабрю 2022 закрыли разрыв (осталось улучшить популярные плагины типа «structure») + сделали крутой импорт.
Возможность крутить шурупы отверткой а не шуриком тоже можно считать за "закрытие разрыва в функционале". Но какое-то оно сомнительное
Основной болью на декабрь 2022г. оставался интерфейс (по словам клиентов). Он был немного другой, пользователи не хотели привыкать. Было принято стратегическое решение — сделать полный клон. Вариант интерфейса «Jira».
Жаль, что нам так и не удалось
заслушать начальника транспортного цехаувидеть в статье примеры интерфейса, который будет... или есть... или что... или когда...????Ниже описание со скриншотами того, что удалось разработать за полгода. Российские разработчики сделали за полгода то, что разрабатывалось и внедрялось 20 лет (первый релиз Jira 2002г.).
Не смешите рынок, а то потенциальные покупатели помрут со смеху - кому продавать будете? ))))
====
Я конечно понимаю, что хочется со всех сил пропиарить свой продукт, но... Нельзя же уж совсем так.
Когда ты слышишь слова "мы сделали клон жиры" и т.д. и потом реально заходишь в этот "клон", то ... ощущения не передать словами: толи плакать хочется, толи смеяться, толи еще чего...
Очень уж "клон" похож на студенческую поделку с основным лозунгом разработки "пофиг как, но чтоб было хоть как-нибудь и быстро". И самое главное - после этого еще с год-два я не пойду смотреть на это изделие, даже если вы выпустите еще сотню статей "мы уже все переделали, у нас прям все ваще ваххх как". Отличная антиреклама.
А потом ты вдруг видишь цену.... )))))
Или Space делали для… эээ, а для кого? Неужели свои собственные разработчики не пользовались своими собственными YouTrack и TeamCity? Такое разве может быть?
А если пользовались — и как они теперь живут, бедные, в трех системах? Или в одной, но урезанной, но зато с коммуникациями?
Не одна версия по уму не может быть правдивой, но как ни крути, а версия должна быть
JetBrains, мы вас теряем? :))
Возникает сразу вопрос: почему не впихнули одно в другое? Ну как так? Или над Space (как обычно) работали совсем другие люди и про YouTrack были «не в курсе», а потом уже было поздно? )))
В итоге то проблема так и не решена:
* есть отдельный инструмент Space для коммуникаций и документации, с расширенной информацией по командам и т.д., в общем, неплохая вещь — ну когда будут готовы процессы для бизнес-подразделений (code-review для документов и т.д.). Да, для разрабов все есть, кроме одного: нет нормального функционала задач. И как они живут? Или подразумевается, что все разрабы, вот все десятки и сотни разрабов (а в будущем и обычных пользователей), настолько дисциплинированы и адекватны, что без ошибок будут делать всю работу и ни разу не пихнут задачу не в тот статус? Роботы? ))
* и есть отдельный инструмент YouTrack для работы над задачами — с воркфлоу и т.д., который частично пересекается по функционалу. Ну а если его сконнектить со Slack, то будут и коммуникации более-менее
И для того, чтобы иметь и тот и тот функционал, пользователи будут все-равно работать в разных системах
Хотя решение объединения систем напрашивается само собой — и тогда бы с чистой душой можно было и использовать и предлагать такой продукт для любой потребности, какая возникнет у компании: хочешь задачи — на, хочешь коммуникации — на, хочешь ci/cd/git/code review — бери, хочешь команды — пожалуйста, хочешь это все вместе — да без проблем
Ыыыыыыыыыы
Ну например возьмем пример, когда есть AD, коннект к внешним СУБД и все воркфлоу обвешаны скриптами — и тут облако не светит. Уж не говоря про требования ФЗ и СБ
ДЦ при 10000 пользователей тоже не светит — там цена невменяемая
Хошь не хошь, а такому клиенту за 3 года надо найти, куда свалить
дальше в лесбольше денег, тем меньше остается мозгов»Атлассиан решили дальше строить свою жизнь исключительно с домохозяйками — а кто еще может работать в облаке? Это же мучительные мучения — взять только одну асинхронную модель, не говоря уж про кучу всего другого, чему нет никаких аналогов в облаке
Честно говоря, не представляю, как крупный клиент с жирной жирой может уйти в облако — это просто невозможно, хоть даже бесплатно оно будет
ДЦ — с ценой, которая озвучена, проще свою жиру написать
Обчим, жира гудбай, атлассиан гудбай, видимо так
Надо искать что-то другое
Не, оно конечно, если вдруг от атласианов начнут валить — ну или сообщать, что свалят — большие и жирные клиенты, оно может и вправит мозги, но что-то я не уверен: если люди решили, что они умеют летать и начали разбег к обрыву, то их уже не остановить
Не нужно его прижимать со всей дури, это действует как раз в обратную сторону — ничего не пилится
Хотя по опыту конечно же мы думаем, что чем сильнее держать и прижимать, тем лучше
Вот тут мультитул отличается от всех остальных — его надо держать очень нежно :), практически чтобы он давил своим весом, ну типа того.
Все это оттого, что он работает через вибрацию насадки относительно материала, а если его сильно прижать, то таких вибраций уже не будет — будут вибрации всего мультитула относительно насадки и материала.
Поэтому у начинающих (как у меня) бывает, что «нифига оно не работает, выкинуть его да и все»
Однако стоит только держать его правильно — и все становится хорошо
Как только работать им научишься — то и сразу проблем нет, зачем и как его использовать
Но таки да, он очень специфический инструмент
И лучше кстати брать его проводным, а не аккумуляторным, потому что аккума очень уж на мало хватает, жрет он быстро их
Но железо и даже алюминь я бы им не пилил — лучше ножовкой по металлу, руками, чем им
Вот дерево/пластик и т.д. — самое то
Нет, не пойдет: JQL используется только для выборки списка заявок по параметрам. К служебным данным он отношения не имеет
И боюсь API не сможет выдать данные по параметрам настройки конкретного экрана на портале сервисдеска
Т.е. данные по заявке то я могу получить разными способами, но вот как называется конкретное поле на конкретном экране конкретного портала — я думаю что только через sql. Может конечно и еще как-то, но мне sql ближе — на нем все быстрее, понятнее и можно добраться до всех данных, какие есть в бд
И кстати, ScriptRunner становится платным — причем очень платным для количества лицензий начиная от 250 (http://www.adaptavist.com/w/continuing-to-develop-scriptrunner-for-jira/). Дешевле купить все плагины JJUPIN и т.д. от кеплера
Ну да, он умеет создавать от указанного пользователя, это хорошо.
Правда я не смог заставить его работать нормально — статистику использования он не показывал
Но если у вас много типов запросов, много категорий, от которых зависит набор полей, если нужны расширенные комментарии к полям и вообще другие названия для них в зависимости от типа и категории — тут только JSD
Он вовремя подоспел — мы перевели всю техподдержку у себя на Жиру
Разработка до этого перешла, через Жиру
Вообще в Жире очень низкий порог вхождения нового пользователя, который ни разу ее не видел и вообще ни с чем таким не работал
Он практически нулевой
Но через email нельзя заполнить никакие поля, кроме описания и темы
А если брать явное создание запросов пользователем, то в Жире можно указать все, что надо (выпадающие списки, даты и т.п.)
JSD дает более удобную работу с этим всем — человек вообще может даже и не знать, как на самом деле выглядит заявка в Жире, подавая заявки через JSD
А Service Desk — это удобная настраиваемая морда для подачи заявок и удобная их обработка: SLA + очереди + отчеты
Настроить можно без проблем, если что-то уже приходилось настраивать в Жире
Есть уже плагин, добавляющий некоторые плюшки к JSD, которых там нет и руки до них у Атлассиана вряд ли быстро дойдут
Или вообще — это не Service Desk :)
Ну в понимании этого термина, как Служба Поддержки пользователей, реагирующая на их запросы
ServiceDesk, если прямо переводить — служба поддержки.
Кого и как вы ей поддерживаете — ваше личное дело, никакие итили и т.д. тут никому не могут ничего указывать
Что есть служба поддержки?
Это заявка пользователя и работы по ней., т.е. простейший баг-трекер. А если обработка не в стиле «принял — обработал — закрыл», то это уже совсем не простейший баг-трекер, а нормальный процесс
Касаемо Жиры
У нас на ней сделан и SD, и процесс разработки, и процессы между отделами компании, и т.д.
А JIRA Service Desk вообще очень сильно продвинул Жиру в смысле приема заявок от пользователей
Надеюсь за недельку закончить
По поводу применимости
Проблема JSD в том, что пользователь должен залогиниться в систему, чтобы написать через JSD заявку
Если у вас все пользователи видят Жиру и нет проблем с количеством лицензий — то смело можно использовать. Если один из этих пунктов в пролете — то остается только по письмам создавать задания от единого универсального пользователя
Если исходить из того, что у нас все хорошо с дисциплиной, то остается только процессы сделать нормальными — а тут поможет и этот набор средств, и любой другой, лишь бы в них уметь работать
Может стоит лучше расписать, чем поможет именно данный инструмент и как с ним работать, чтобы он помог.
Хотя я боюсь, что обычно все наоборот: и процессы есть (вроде), и средств полно — а толку нет, потому что нет дисциплины. И это самое сложное. После процессов.
Кстати, ко всем средствам я бы добавил очень важное требование — легкое изменение под требования процессов. Мы пока поставили процессы, раза три их меняли, а вместе с ними и процессы трекера. Но он позволяет это делать относительно быстро и просто. А если нет? :)