Как стать автором
Обновить
8
0

Пользователь

Отправить сообщение

В очередной раз происходит потеря смысла :)

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

Т.е. задача не в том, чтобы у тебя отдельно в ветке лежал код subsystem, а отдельно subsystem_ui.

А в том, чтобы ты начал разрабатывать классы ядра, разработал первую версию за день и к вечеру уже слил ее.

Потом на основе этих классов ты создал subsystem и также сделал первую версию за максимально короткое время.

И, главное, за исключением ситуации с фиксом багов в том коде, который ты активно используешь, в один момент времени ты работаешь над одним компонентом. А значит - упрощаешь себе не только синхронизацию с main, но и накладываешь на себя системные ограничения by design, что, как мы знаем, есть едва ли не единственный путь к снижению нагрузки на разработчика :)

Это не является коммерческой тайной. Данные о доходах могут проходить как персональные данные, и тем самым подпадать под статью 88 ТК РФ.

Меня сейчас, возможно, закидают всяким, но, блин, все эти выплаты - очень позитивные новости.

Я как-то, когда думаю о детях и около них, рассчитываю на то, что я с ними буду "один на один" и как платить за все самостоятельно.

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

Предложение для развития:

  1. Привести визуализацию к абсолютным значениям, чтобы можно было объем транзакций оценить глядя на график

  2. Добавить, например, в виде "толщины" колбасы - количество транзакций :)

  3. В этом случае получится оценить и объем, и число транзакций в категории

  4. Если разделить категории на "кучи"(node heaps) и в качестве ребра к1->к2 использовать транзакцию в к2 следующую за транзакцией в к1, и уложить граф с помощью метода укладки вроде Force Plot - можно будет показать динамику перехода расходов :)

Я сейчас один умный вещь скажу, вы только не обижайтесь.

В отношениях с работодателем есть два первичных документа: трудовой договор (со всеми дополнительными соглашениями) и должностная инструкция.

По сути, если прочитать их и те документы на которые они ссылаются, то уже будет на 99% понятно как в непонятной ситуации себя вести с работодателем.

А оставшийся процент - это истории завязанные на трудовой кодекс, относительно которых как правило и нужны консультации.

Ну, а дальше есть простых правила:

  1. Все должно быть записано: разговоры и взаимодействия с работодателем, результаты работы и так далее. Если не записано - считай не было.

  2. Если что-то не прописано в документах явно - надо идти копать в трудовой кодекс.

А вы пробовали что-то делать с этим?

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

И ситуации, которые вы описываете, когда водитель делает фигню, конечно, есть. Но случаются они архирекдко. Потому что значительную их часть Яндекс находит сам. И даже когда одна из ситуаций случается, то по итогу пишется в поддержку, и воитель-причина неприятной ситуации больше на маршруте не появляется. А вам возвращают деньги, если их вообще спишут.

История с детскими креслами, конечно, так легко не решится. Но у меня вопрос - вы пробовали заказать Лидер или Максим с детским креслом до того как это появилось в Я.Такси?:) не знаю, как в вашем городе, но в Новосибирске детские кресла в такси вообще появились только когда пришел Яндекс. Ну и во всех крупных городах заказать такси с одним детским креслом сейчас проблемой не является, а с двумя... Вы демографию страны видели? Два детских кресла в такси, вне зависимости от Яндекса, маловероятно. Просто потому, что пользы для водителя от второго очень мало, а сложностей изрядно.

То же касается и "поездок, когда скоро будет повышенный спрос": году так в 2010 в Новосибирске уехать из аэропорта просто всегда стоило от тысячи рублей. Иногда сильно дороже, но дешевле - не было. Сейчас я уезжаю на правый берег (25км), а то и в академгородок (50км) в среднем за 1000-1600 рублей, и не на экономе. При этом, иногда, если я прилетаю в разрыв между рейсами, то получается уехать и за 600-700 рублей. То есть, в целом, для меня стоимость такси с учётом инфляции упала раза в два, а иногда я вообще можно сказать бесплатно уезжаю.

И, нет, Яндекс.Такси не идеальный сервис. Да, они иногда очень жёстко косячат. И, да, с их монополией связано очень много потенциальных рисков. Вот только то, о чем пишите вы - или не связано с Яндекс.Такси, или легко в рамках экосистемы решается.

You can do better.

Во-первых, привет коллегам от ML-команды Евраза =)
Во-вторых, классный рассказ про нюансы, мы что-то подобное регулярно рассказываем заказчикам "почему это так дорого" =)
В-третьих, что таки у вас по экосистемным решениям? =)

В этом и история, что данных, в целом, много =)
А ещё больше данных - которых нет и не будет =) Например, в печи может иметься дырка (это не шутка, не в этом конкретно кейсе, но ситуация реальная =)), через которую будет отходить тепло и часть газов/взвеси. И это будет нелинейно влиять на традиционную физическую формулу.
Теоретически, построить физ.мат. модель с учетом всех дополнительных нюансов тех.процесса можно... Но как правило это проект стоимостью в десятки, а то и в сотни миллионов рублей =)

Применение ML в таких задачах - это как раз попытка по косвенным признакам вывести зависимости от "скрытых" данных и восстановить ту самую аппроксимационную функцию на основе данных и сделать это дешевле и быстрее, чем при попытке честного моделирования.
При этом "наивная модель" по нескольким точкам (обычно её зовут baseline) - является первым шагом для построения статистической модели =) И если он уже даёт результат - статистическую модель обычно уже не строят.

Очень жаль, что большая часть комментаторов так однобоко смотрит на ситуацию.)

Минцифры нужно отдать должное, они сделали невероятно много хорошего для ИТ специалистов работающих на российские компании. Более того, в определенные моменты показали высочайший уровень квалификации и понимания ситуации, например, когда началась мобилизация.

От себя, как от руководителя довольно крупного ИТ подразделения могу сказать разве что спасибо всем сотрудникам минцифры и лично Максуту Игоревичу :) Мои специалисты благодаря их действиям чувствуют себя существенно лучше и спокойнее, благодаря их усилиям.

Если получится создать конкурента ASML в любом смысле этого слова - никто не будет говорить про "выпуск только для армии". Экспорт начнется в тот же момент, когда за рубежом появится спрос, скорее всего :)

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

Теоретически, в современной России может сложиться единственная точка на земле в обозримом будущем, где подобное может стать оправданным и осмысленным :) не более того

Обещания и реальность - штука сильно разная :)

Хотя история с безмасочной фотолитографией и звучит действительно очень перспективно, но подводных камней на этом пути - умопомрачительное количество. А потому ни одной оценке "за столько лет и денег - мы сделаем" я бы не верил :)

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

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

Я чуть-чуть перефразировал бы =)

Теория - даёт тебе точную и строгую формулу с парой констант, которые работают "условно всегда"
При этом в формуле есть множество значений, которые на предприятии ТОЧНО измерить невозможно =)
И если подставлять неточные значения - получается неточный результат: Garbage in - garbage out =)

Дооборудовать более точными измерительными средствами обычно капец как дорого =)
В итоге, как правило, для тех значений, которые не могут точно измерить, подбирают "поправочные коэффициенты", которые дают похожий на правду результат в большинстве случаев =)
А остальную формулу используют "как есть" =)

Надо понимать с чем сравниваться :)

У технологов процент попадания в этом наборе данных порядка 70 :)

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

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

Участники подали несколько интересных идей с точки зрения генерации признаков, которые мы ранее не использовали, так что вероятно мы ещё улучшим качество)

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

Во-первых, у нас используется не нейросеть, а ансамбль деревьев решений :)

В статье есть ссылка на библиотеку SHAP - она очень полезна для оценки влияния факторов на работу моделей :)

И строит очень удобные графики, которые мы с технологами нередко обсуждаем.

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

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

А если что-то где-то сломано, то нужно не описывать это, а починить :)

Записать, что была поломка и провести расследование, конечно, тоже нужно, но это уже касается не оптимизации КХП, а задач predictive maintenance ;)

А про публичность и секретность приглашаю пообщаться через две недели на конференцию Saint HighLoad++ 2021, я там как раз чуть подробнее расскажу про технику касающуюся этого проекта и про "направленность на opensource" ;)

По первому пункту - очень и очень спорно :)

Есть, конечно, ретрограды принципиальные, но в большинстве случаев в руководстве сидят люди, по крайней мере, хорошо понимающие экономику :) и если объяснить им какую пользу для их интересов принесет проект (в данном случае повышение экономической эффективности предприятия) - одобрение получается довольно легко :)

А "в штыки" воспринимаются как правило идеи, которые не учитывают интересов спонсора/ЛПРа :)

И это так не только в бизнесе работает, как правило :)

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

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

И в такой ситуации в третьем пункте будет другой вопрос: не "что ещё можете предложить?", а "а вот это можете?" :)

И это прекрасно, потому что в финале наша общая цель сделать так, чтобы всем было хорошо :)

Мы делаем допущение, что параметры коксования за исключением помола и периода коксования достаточно стабильны :)

Как показывает практика такое допущение вполне оправдано :)

Технологии тоже не высказали к этому допущению критики.

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

Спасибо за то, что ответили :)

Доменная печь и коксовая печь - это разные вещи :) в данном случае это не доменная печь, а именно коксовая, то, что ниже названо "батареей"

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

За счёт чего модели опирающиеся на предыдущий результат по качеству ведут периодически к драматическим ошибкам :)

Ваше опасение понятно, но, на мой взгляд, не обосновано :)

Мы даже в посте постоянно обращаем внимание - модель не есть "истина в последней инстанции" :)

Модель - просто ещё один инструмент в руках человека.

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

Если угодно - это "станок 21го века" :) и разве люди разучились шить, когда изобрели ткацкий станок?:) Нет, просто механика изменилась :) и появился "инженер по настройке ткацких станков" :)

Всю человеческую историю индивидуальное мастерство "запечатывается" в инструменты. Мастерство при этом не пропадает, просто становится нишевым, а массовый рынок заполняет товар ремесленный.

Но разве это плохо, что литой колесный диск стоит 3-4 тысячи рублей, а 40-50 как его кованые братья? :)

Не, зарплату не урезают, вроде :)

Такой цели точно не стояло!)

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

Если есть вопросы - задавайте, будем рады ответить :)

1

Информация

В рейтинге
5 078-й
Зарегистрирован
Активность