От себя добавлю просто пример про стабильный интерес.
Я недавно ремонт делал и заморочился за локальное и понятное мне (тупое и примитивное) управление всеми относительно умными устройствами, которые у меня есть. Поскольку их зоопарк (где-то 4 вендора), нужно было что-то однообразное и пока это MQTT.
Помимо MQTT у всех есть свои приложения, в которых по-разному неудобная логика - где-то максимум три правила в расписании, где-то расписание игнорит то, что я 1 минуту назад прибор выключил, потому что он мне мешает и снова его включает, где-то ещё что-то. Расстраивает водонагреватель от Electrolux, который отучить от облака у меня пока никак не получается.
Можно было бы это всё в Home Assistant засунуть, но мне хотелось тупой дом, поэтому я накостылял где-то 450 строчек (из которых около 100 - правила на самопальной структуре в YAML) свой велосипед и сижу довольный. Если бы мне для одного вендора пришлось бы CoAP тащить, для другого Thread, я бы сильно расстроился :)
И вот имея такой велосипед на руках я стою перед вторым ремонтом в доме и уже понимаю, что буду на всю технику смотреть сильно внимательнее и то, что работать в режиме локального MQTT не умеет - тупо не куплю.
Отчего же бестолку. Было бы желание - а толк найдётся. На тестовом слое можно выполнить выдернутый из логов запрос, а уж наполнение базы тестового слоя приближенными к реальности объёмами - это другой вопрос. Во всяком случае это будет лучше чем (в порядке уменьшения лучшести):
Аж захотел написать "зеркальную" статью с диаметрально противоположными тезисами с точки зрения тех самых сотрудников, которые ищут причины почему что-то не сработает. Не просто ведь так они это делают?
Тоже на 740 синхронизация (приём книжек по почте) отвалилась без объяснения причин (просто пишет "Ошибка синхронизации") в итоге от Wi-Fi уже никакого смысла и не осталось. Ладно хоть по кабелю скидывать книги пока не запрещают.
Очень сомнительный аргумент про "если задача нужна, её заведут снова с новым контекстом". То есть мы получим а) дубль, б) потеряв половину контекста.
Я в целом вижу категорию задач - выпрямить какой-то косяк в системе, который приводит к периодическому ручному труду. Если бросаться сразу всё автоматизировать - задачи с большим выхлопом пострадают, если ничего не записывать (и не делать периодически) - система обрастает такими "ручниками". Я с ними работаю следующим образом - записываю с низким приоритетом и потом каждый раз, когда занимаюсь таким "ручником" и это бесит - добавляю комментарий "снова выползло тут", по возможности пополняя тот самый контекст. Как только комментариев становится больше трёх, возвращаем "нормальный" приоритет и задача как правило захватывается в следующем спринте, если нет чего-то прям нереально горящего.
Аргумент про "команда не доверяет бэклогу" тоже какой-то натянутый. Сравнительно самостоятельной команде от бэклога нужна линейная сортировка в порядке взятия в работу, кончились задачи - взял одну из 3-5 задач сверху, с которой можешь справиться. Способов реализации такой сортировки полно: очереди (а-ля месяц-квартал-год-потом), матрица Эйзенхауэра, ручками, случайно перемешивая, просто по приоритету, по (про)сроку итд. Если сверху ещё и фильтры накинуть (специализация работника + незаблокированные ничем задачи), вопрос его самостоятельного выбора следующей задачи при исчерпании задач в спринте - выеденного яйца не стоит.
Вот если заведённые сотрудником задачи удаляют - это как раз отличный повод перестать доверять бэклогу, как ненадёжному хранилищу, а также в случае с категорией задач, описанной выше, перестать их откладывать и хвататься за всё и сразу, забивая на приоритеты и текущую задачу.
Возможно, наши мнения не конфликтуют - если вы имеете в виду осознанную отмену задачи её же автором, я целиком согласен. Видишь, что не делается и впереди туча других задач - тогда отмена вполне легальна.
Вас минусуют за избыточное обобщение. Такие люди действительно есть, но их 1-2% от пользователей андроида, остальным лишь бы работало. Таки громкое меньшинство.
Но... раз у мужиков в 99% случаев трэш полнейший, то.. не так уж эта сугубо мужская отрасль хорошо мужикам подходит, выходит?:D
P.S: да, девушек мало в отрасли. Над джунами смеяться и по джунам оценивать - скверная практика. Если их отсеять, то за ~14 лет стажа, с двумя коллегами-девушками уровнем выше джуна с кем довелось работать, трэша не было. Это выходит, ситуация в 100 раз лучше? (100% без трэша VS 99% с трэшем). </абсурд>
Автор всё же говорит о принципиально другой ситуации, когда языковая модель в полном контексте общей кодовой базы проекта и может переиспользовать имеющиеся в ней функции и библиотеки, плясать от того, какие зависимости уже подключены, какие ещё нет. И если у неё не получается это, у компании есть ресурсы ей помочь научится так делать, даже если это не выгодно в моменте - они вполне могут относиться к этому как к капитальному вложению и, в принципе, будут правы. При этом вопроса утечки кода не стоит, т.к. для них это будет in-house система. При этом у такой модели будут дополнительные возможности для исполнения, например прогон линтеров, тестов, профилировщиков и бенчмарков, доступом к системам мониторинга, сбора метрик и ошибок, как обратной связи для самоанализа. Да даже тестовым стендом можно обеспечить, чтобы обкатывала релизы, которые сама и сгенерировала. С таким подспорьем моделька, как мне кажется, таки может обеспечивать качественный сдвиг по сравнению с условным copilot / чатом.
Вряд ли в ближайшие пять лет это будет доступно всем, но если будут делать as a service, на бизнес и отношение к собственным наработкам оно таки может повлиять и сдвинуть грань, между
да в смысле выложить в гугл исходники, в разработку которых мы вбухали не один лям?!
в смысле дать third party системе с доступом из интернета права на управление закрытым контуром информационной системы?!
и
да нахер мне ещё N лямов в зарплаты разработчиков вбухивать, когда за 24 часа и месячную ЗП миддла эта моделька пять фич до прода докатит с меньшим числом багов и простоев чем эти остолопы?!
Разумеется в какой-то момент что-то будет идти не так, но когда такого не было? :)
Кажется от перевода стоит воздержаться если есть две вещи одинаково переводящиеся. Либо добавлять примечание переводчика при первом переводе термина. Если конфликта переводов в текущем контексте нет, оставлять англицизм кажется лишним. Контекстом, наверное, стоит считать всю книгу или серию.
Когда-нибудь я реализую мегакиллерфичу, которая по одному значению из env мягко (чтобы call_count'ы работали) вырубает все моки и превращает имеющиеся юниты в интеграционные тесты и заживём :D
Меня тоже хорошенько закорёжило натягивание общих ценностей и их интерпретаций на всю сеть и всех её пользователей и я решил немного пофантазировать, а как бы федиверс ещё дальше зафрагментировать так, чтобы все были довольны.
Если коротко - ввести на уровне протокола ActivityPub сегменты - группы инстансов, устраивающих друг друга по используемому серверному ПО, поддерживаемому клиентскому ПО, личностям администрации, консенсусу в политике модерации и федерированию с другими сегментами.
Ну суть мысли-то не меняется, почему
знаменитостистудии не оседлали эту волну?)От себя добавлю просто пример про стабильный интерес.
Я недавно ремонт делал и заморочился за локальное и понятное мне (тупое и примитивное) управление всеми относительно умными устройствами, которые у меня есть. Поскольку их зоопарк (где-то 4 вендора), нужно было что-то однообразное и пока это MQTT.
Помимо MQTT у всех есть свои приложения, в которых по-разному неудобная логика - где-то максимум три правила в расписании, где-то расписание игнорит то, что я 1 минуту назад прибор выключил, потому что он мне мешает и снова его включает, где-то ещё что-то. Расстраивает водонагреватель от Electrolux, который отучить от облака у меня пока никак не получается.
Можно было бы это всё в Home Assistant засунуть, но мне хотелось тупой дом, поэтому я накостылял где-то 450 строчек (из которых около 100 - правила на самопальной структуре в YAML) свой велосипед и сижу довольный. Если бы мне для одного вендора пришлось бы CoAP тащить, для другого Thread, я бы сильно расстроился :)
И вот имея такой велосипед на руках я стою перед вторым ремонтом в доме и уже понимаю, что буду на всю технику смотреть сильно внимательнее и то, что работать в режиме локального MQTT не умеет - тупо не куплю.
Отчего же бестолку. Было бы желание - а толк найдётся. На тестовом слое можно выполнить выдернутый из логов запрос, а уж наполнение базы тестового слоя приближенными к реальности объёмами - это другой вопрос. Во всяком случае это будет лучше чем (в порядке уменьшения лучшести):
ничего
просто SQL-запрос
Explain с локалхоста вообще без данных
Ясно.
Explain прикладывать надо, а не SQL :)
Аж захотел написать "зеркальную" статью с диаметрально противоположными тезисами с точки зрения тех самых сотрудников, которые ищут причины почему что-то не сработает. Не просто ведь так они это делают?
Тоже на 740 синхронизация (приём книжек по почте) отвалилась без объяснения причин (просто пишет "Ошибка синхронизации") в итоге от Wi-Fi уже никакого смысла и не осталось. Ладно хоть по кабелю скидывать книги пока не запрещают.
Осталось для пешеходов что-то придумать.
Так в прошлом-то переключатели были огого, а в будущем будут хехехе.
Интересно, часто ли ставят в качестве пин-кода один из четырёхнаборов цифр из номера карты?
Очень сомнительный аргумент про "если задача нужна, её заведут снова с новым контекстом". То есть мы получим а) дубль, б) потеряв половину контекста.
Я в целом вижу категорию задач - выпрямить какой-то косяк в системе, который приводит к периодическому ручному труду. Если бросаться сразу всё автоматизировать - задачи с большим выхлопом пострадают, если ничего не записывать (и не делать периодически) - система обрастает такими "ручниками". Я с ними работаю следующим образом - записываю с низким приоритетом и потом каждый раз, когда занимаюсь таким "ручником" и это бесит - добавляю комментарий "снова выползло тут", по возможности пополняя тот самый контекст. Как только комментариев становится больше трёх, возвращаем "нормальный" приоритет и задача как правило захватывается в следующем спринте, если нет чего-то прям нереально горящего.
Аргумент про "команда не доверяет бэклогу" тоже какой-то натянутый. Сравнительно самостоятельной команде от бэклога нужна линейная сортировка в порядке взятия в работу, кончились задачи - взял одну из 3-5 задач сверху, с которой можешь справиться. Способов реализации такой сортировки полно: очереди (а-ля месяц-квартал-год-потом), матрица Эйзенхауэра, ручками, случайно перемешивая, просто по приоритету, по (про)сроку итд. Если сверху ещё и фильтры накинуть (специализация работника + незаблокированные ничем задачи), вопрос его самостоятельного выбора следующей задачи при исчерпании задач в спринте - выеденного яйца не стоит.
Вот если заведённые сотрудником задачи удаляют - это как раз отличный повод перестать доверять бэклогу, как ненадёжному хранилищу, а также в случае с категорией задач, описанной выше, перестать их откладывать и хвататься за всё и сразу, забивая на приоритеты и текущую задачу.
Возможно, наши мнения не конфликтуют - если вы имеете в виду осознанную отмену задачи её же автором, я целиком согласен. Видишь, что не делается и впереди туча других задач - тогда отмена вполне легальна.
Вас минусуют за избыточное обобщение. Такие люди действительно есть, но их 1-2% от пользователей андроида, остальным лишь бы работало. Таки громкое меньшинство.
Но... раз у мужиков в 99% случаев трэш полнейший, то.. не так уж эта сугубо мужская отрасль хорошо мужикам подходит, выходит?:D
P.S: да, девушек мало в отрасли. Над джунами смеяться и по джунам оценивать - скверная практика. Если их отсеять, то за ~14 лет стажа, с двумя коллегами-девушками уровнем выше джуна с кем довелось работать, трэша не было. Это выходит, ситуация в 100 раз лучше? (100% без трэша VS 99% с трэшем). </абсурд>
Чисто для души и для желания систематизировать кашу в голове до кристально чистого знания.
Автор всё же говорит о принципиально другой ситуации, когда языковая модель в полном контексте общей кодовой базы проекта и может переиспользовать имеющиеся в ней функции и библиотеки, плясать от того, какие зависимости уже подключены, какие ещё нет. И если у неё не получается это, у компании есть ресурсы ей помочь научится так делать, даже если это не выгодно в моменте - они вполне могут относиться к этому как к капитальному вложению и, в принципе, будут правы. При этом вопроса утечки кода не стоит, т.к. для них это будет in-house система. При этом у такой модели будут дополнительные возможности для исполнения, например прогон линтеров, тестов, профилировщиков и бенчмарков, доступом к системам мониторинга, сбора метрик и ошибок, как обратной связи для самоанализа. Да даже тестовым стендом можно обеспечить, чтобы обкатывала релизы, которые сама и сгенерировала. С таким подспорьем моделька, как мне кажется, таки может обеспечивать качественный сдвиг по сравнению с условным copilot / чатом.
Вряд ли в ближайшие пять лет это будет доступно всем, но если будут делать as a service, на бизнес и отношение к собственным наработкам оно таки может повлиять и сдвинуть грань, между
и
Разумеется в какой-то момент что-то будет идти не так, но когда такого не было? :)
По этой же причине и vim уязвим, выходит.
Кажется от перевода стоит воздержаться если есть две вещи одинаково переводящиеся. Либо добавлять примечание переводчика при первом переводе термина. Если конфликта переводов в текущем контексте нет, оставлять англицизм кажется лишним. Контекстом, наверное, стоит считать всю книгу или серию.
Когда-нибудь я реализую мегакиллерфичу, которая по одному значению из env мягко (чтобы call_count'ы работали) вырубает все моки и превращает имеющиеся юниты в интеграционные тесты и заживём :D
Меня тоже хорошенько закорёжило натягивание общих ценностей и их интерпретаций на всю сеть и всех её пользователей и я решил немного пофантазировать, а как бы федиверс ещё дальше зафрагментировать так, чтобы все были довольны.
Если коротко - ввести на уровне протокола ActivityPub сегменты - группы инстансов, устраивающих друг друга по используемому серверному ПО, поддерживаемому клиентскому ПО, личностям администрации, консенсусу в политике модерации и федерированию с другими сегментами.
Если длинно, то вот статья в моём бложеке
А накиньте почитать статейку с критикой ActivityPub, с которой вы согласны.