а раз их надо указать значит их будут фейкать

а раз их будут фейкать значит их надо проверять и сабмитить

Правда его можно редактировать при выполнении(закрытии задачи)

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

Эм, я хз...

ну поле же руками вносят... типа я потратил на эту задачу 7 часов.

а в месяц по человеку суммируешь а он 500 часов наработал.

ка кжи так думаешь...

Я так думаю, что поле можно сделать ридонли

Я про это поле, после нажатия на кнопку стоп

Сейчас гляну

как же так думает hr,ДА БЛЯ вы всем там ахирели думает бухгалтер

как же так думает hr,ДА БЛЯ вы всем там ахирели думает бухгалтер

))) ну часов 250 у некоторых dev у нас есть в месяц

классна.

Но там один человек и он ведущий разраб и время ему себе прибавлять нафиг не надо ?

"нафиг не надо" ! = "система надежно считает потраченные часы"

Нельзя spent time сделать ридонли

а речь же не сделать его в ридонли.

а в коммите этого времени...

ну да ладно это вообще разговор для не здесь.

?

Ну по большому счёту этот разговор и для здесь тоже

ну короче такие вот укуренные темы они возникают в головах у менеджеров.

менеджеры приносят это бизнес технолгам. а те программистам.

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

Хорошая штука на самом деле не для hr, а для руководителя подразделения, что б видеть реальную загрузку своих подчененных

сильно все зависит от коллектива.

все эти ваши естимейты и таймспенты...

сильно все зависит от коллектива.

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

все эти ваши естимейты и таймспенты...

Эстимейты в часах самая беспомощная вещь на свете

Эстимейты в часах самая беспомощная вещь на свете

Почему?

Ну потому что они работают только в случае хорошо известных много раз проделанных действий.

И в малых масштабах

Ну потому что они работают только в случае хорошо известных много раз проделанных действий.

Это заблуждение.

Это заблуждение.

Совершенно верно, они вообще никогда не работают

Человеки не умеют во время

хорошо человеки умеют сравнивать разные штуки

это обычная штука, а вон та штука примерно в три раза больше первой

а вот третья штука, где-то 1/4 от первой

Сколько времени тебе надо чтобы сделать третью штуку? Да хрен знает. В четыре раза меньше, чем для того чтобы сделать первую

Поэтому эстимейты в часах это такой способ чем-то занять людей, они всё равно неправильные, всегда

но все делают вид, что чем-то заняты

Вы сейчас пишите о теоритическом времени разработки - т.е. стоимости затраченного времени? Мы же общались на тему фактического времени затраченного на писание кода.

Ну Дак померяйте время, которое таск в разных стейтах находился

Называется cycle time

Совершенно верно, они вообще никогда не работают

И в космос летают по чистой случайности, и самолёты вовремя прилетают по божьей воле?

Бизнесу понятны только метрики сроки/ресурсы, так что от этого не уйти.

https://sam.riolet.com/ странная херовинка

И в космос летают по чистой случайности, и самолёты вовремя прилетают по божьей воле?

А я не говорил, что эстимейт времени нельзя сделать, я говорил что спрашивать у разработчика эстимейт бесполезно

Чуваки, вот смотрите. Есть команда, пока небольшая. У команды нет офиса, нет никакой "ЛВС", команде хочется SSO, но гугл кажется дорогим.

Чуваки, вот смотрите. Есть команда, пока небольшая. У команды нет офиса, нет никакой "ЛВС", команде хочется SSO, но гугл кажется дорогим.

storagebox в хетзнере

и самим поднимать любым программным продуктом

вот интересуют как раз программные продукты

ааа

я вообще смотрю в сторону Atlassian Crowd

но там есть проблема и большая, как только команда выйдет за пределы 50 юзеров, он станет неприлично дорогим

Хм, да он золотым получается

угу

Тут вариант только искать opensource

Увы ничего подсказать не могу, ен пользовался

а это разве не правильно ?

Денис, это не правильно потому-что без управления данными, без культуры вот этой - вы будете платить всё больше денег не понятно ради чего. У нас уже так, накопили дохера данных, о некоторых вообще не понятно, на кой они. Но лежат. Пока просто лежат - чорт бы с ними, а как надо железо новое покупать или переезжать в эти ваши облака - так эта неряшливость в данных - оно может дорого стоить

Чуваки, вот смотрите. Есть команда, пока небольшая. У команды нет офиса, нет никакой "ЛВС", команде хочется SSO, но гугл кажется дорогим.

делать ссо самим, не имея подобного опыта - оно может быть более дорогим, чем взять гугл тот же

ERROR: S client not available

Денис, это не правильно потому-что без управления данными, без культуры вот этой - вы будете платить всё больше денег не понятно ради чего. У нас уже так, накопили дохера данных, о некоторых вообще не понятно, на кой они. Но лежат. Пока просто лежат - чорт бы с ними, а как надо железо новое покупать или переезжать в эти ваши облака - так эта неряшливость в данных - оно может дорого стоить

Ну я же приводил пример что ребята с яндексами решили что сырые данные лучше чем никаких потом

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

А культура, на мой взгляд, она не про то что бы не налить лишнего, она про то что бы потом убрать за собой )

Не, смотри. Есть бизнес-риски, есть экономика предприятия. Например ты сторишь все данные на с3, чтобы считать проще было

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

Пока у тебя много бабла или мало данных - можно жить как-то

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

В целом - жить сильно лучше, если ты заранее думаешь про то, как ты эти данные использовать будешь

А не как обычно

У нас сейчас переезды, миграции - и мы в полной мере огребаем все минусы этого подхода (сохраним, а дальше разберемся)

именно поэтому желательно хранить максимально широкую копию 1го варианта всех данных, и уметь ее резат ьи считать по ней что угодно, не правда ли ?

А тратим ресурсы, чтобы разбирать все эти сотни etl-обработок, кто что куда от чего почему и кто в конечном виде это использует

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

данные задублированы на хдфс

зачем их где-то еще хранить

вы, наверное, метрики по логам nginx считаете

каждые сутки сгружаются логи nginx в обработку - обрабатываются - и всё, с фронтов эти логи можно удалять

либо я не понял :)

да, но получается все равно ты оставил хранить сырые данные

это если выбран подход "не выбирать подход"

а так - ты посчитал деривативы - и сохранил только их

а сырые данные у тебя вычистились

а чем хранение дериватива лучше ? ) значение меньше ? инт короче ?)

и то, по хорошему у тебя не деривативы посчитались и остались

а я пишу, да :)

у тебя есть понятная цепочка получения ценности из данных, в данном случае - из этих вот деривативов

сырые данные никуда не вычистились

они остались на hdfs

если цепочки получения ценности нет - то может и данные нафиг не нужны?

ценность данных это как акции ) то стоит то нет )

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