Аж захотел написать "зеркальную" статью с диаметрально противоположными тезисами с точки зрения тех самых сотрудников, которые ищут причины почему что-то не сработает. Не просто ведь так они это делают?
Тоже на 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 сегменты - группы инстансов, устраивающих друг друга по используемому серверному ПО, поддерживаемому клиентскому ПО, личностям администрации, консенсусу в политике модерации и федерированию с другими сегментами.
Подумал тут, что в альтернативной вселенной это бы могло удобно решиться с помощью D-Pad (не стрелки, отдельно, но и не теряющиеся в numpad'е).
вправо - добавить текущую позицию в стек закладок
влево - убрать её из стека
вверх - предыдущая позиция
вниз - следующая позиция
Наверное при очень сильном желании такое даже в PyCharm через хоткеи и закладки можно замутить.
Upd: 8 минут спустя захотел такое на планшете, чтобы скакать между схемами материнки в PDF (новая пекарня не включается, судя по всему напутал с контактами PWR SW, к клавиатуре и компу не подберёшься, потому что стол занят новым системником).
Аж захотел написать "зеркальную" статью с диаметрально противоположными тезисами с точки зрения тех самых сотрудников, которые ищут причины почему что-то не сработает. Не просто ведь так они это делают?
Тоже на 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, с которой вы согласны.
А чем постман так завлёк?)
InnerSource с форками и подпуливанием из апстрима и раз в годик "чо мужики, мож замержимся, а частности наследованием внутри проектов заткнём?"
Главное апстрим не потерять, хотя...
Подумал тут, что в альтернативной вселенной это бы могло удобно решиться с помощью D-Pad (не стрелки, отдельно, но и не теряющиеся в numpad'е).
вправо - добавить текущую позицию в стек закладок
влево - убрать её из стека
вверх - предыдущая позиция
вниз - следующая позиция
Наверное при очень сильном желании такое даже в PyCharm через хоткеи и закладки можно замутить.
Upd: 8 минут спустя захотел такое на планшете, чтобы скакать между схемами материнки в PDF (новая пекарня не включается, судя по всему напутал с контактами PWR SW, к клавиатуре и компу не подберёшься, потому что стол занят новым системником).
Скорее порешавшие все висящие вопросики перед окончательным отъездом.
Проиграют обои.