У меня есть пример, когда осмысленно не закрывал файлы. Это утилиты, единственная задача которых - обработать файл. Контекстный менеджер в таком случае уже существует и называется "процесс операционной системы". Завершается он - закрываются и все его файлы :)
Образование. Новый стандарт беспроводной связи расширит возможности для дистанционного и смешанного обучения, обеспечив стабильное подключение большого числа учащихся и преподавателей к образовательным платформам и ресурсам.
Не верю я, что на дистанционке вопрос количества подключающихся удалённо имеет бутылочное горлышко в виде локальной беспроводной сети.
«30 минут физической активности умеренной интенсивности в неделю, при наличии занятий 52 недели в году, связаны с дополнительными 0,010677 годами жизни».
Стало интересно, насколько нелинейна формула и сколько часов выдаст 1 час тренировок 1, 2 или 3 раза в неделю. Или 30 минут 6 раз в неделю. В упор не нашёл числа 0,010677 в статье, которую цитируете в конце. Запятую как разделитель на точку менял. Точность сокращал. Можете ткнуть носом, с какой страницы вы это взяли?
Глянул на отчёт, но не смог правильно истолковать методологию работы с источниками данных. Испытываю подозрение, что часть айтишников, ворвавшись в айтишную ипотеку, как в способ сбережения средств, сдают теперь эту недвижку вбелую, оформившись как самозанятые, ибо это дешевле, чем НДФЛ и ИП. При этом статус самозанятого не отменяет трудовую деятельность в найме. Сам сдаю так, плачу на текущий момент 3%, т.к. оказываю услугу физикам и пока есть налоговый бонус (1%, 10 000₽). Из коробки есть онлайн-чеки, можно заявлять доход не делясь данными об этом с банками. Я обычный русский айтишник, никакой миска рис за комментарий.
Привязка карты и переход в приложение банка для оплаты - это несколько разные подходы с разным уровнем доверия к продавцу. Лично мне второй предпочтительнее, разбрасываться реквизитами карты на формах, пусть и с красивой PNG'шкой PCI-DSS, не хочется.
От себя добавлю просто пример про стабильный интерес.
Я недавно ремонт делал и заморочился за локальное и понятное мне (тупое и примитивное) управление всеми относительно умными устройствами, которые у меня есть. Поскольку их зоопарк (где-то 4 вендора), нужно было что-то однообразное и пока это MQTT.
Помимо MQTT у всех есть свои приложения, в которых по-разному неудобная логика - где-то максимум три правила в расписании, где-то расписание игнорит то, что я 1 минуту назад прибор выключил, потому что он мне мешает и снова его включает, где-то ещё что-то. Расстраивает водонагреватель от Electrolux, который отучить от облака у меня пока никак не получается.
Можно было бы это всё в Home Assistant засунуть, но мне хотелось тупой дом, поэтому я накостылял где-то 450 строчек (из которых около 100 - правила на самопальной структуре в YAML) свой велосипед и сижу довольный. Если бы мне для одного вендора пришлось бы CoAP тащить, для другого Thread, я бы сильно расстроился :)
И вот имея такой велосипед на руках я стою перед вторым ремонтом в доме и уже понимаю, что буду на всю технику смотреть сильно внимательнее и то, что работать в режиме локального MQTT не умеет - тупо не куплю.
Отчего же бестолку. Было бы желание - а толк найдётся. На тестовом слое можно выполнить выдернутый из логов запрос, а уж наполнение базы тестового слоя приближенными к реальности объёмами - это другой вопрос. Во всяком случае это будет лучше чем (в порядке уменьшения лучшести):
Аж захотел написать "зеркальную" статью с диаметрально противоположными тезисами с точки зрения тех самых сотрудников, которые ищут причины почему что-то не сработает. Не просто ведь так они это делают?
Тоже на 740 синхронизация (приём книжек по почте) отвалилась без объяснения причин (просто пишет "Ошибка синхронизации") в итоге от Wi-Fi уже никакого смысла и не осталось. Ладно хоть по кабелю скидывать книги пока не запрещают.
Очень сомнительный аргумент про "если задача нужна, её заведут снова с новым контекстом". То есть мы получим а) дубль, б) потеряв половину контекста.
Я в целом вижу категорию задач - выпрямить какой-то косяк в системе, который приводит к периодическому ручному труду. Если бросаться сразу всё автоматизировать - задачи с большим выхлопом пострадают, если ничего не записывать (и не делать периодически) - система обрастает такими "ручниками". Я с ними работаю следующим образом - записываю с низким приоритетом и потом каждый раз, когда занимаюсь таким "ручником" и это бесит - добавляю комментарий "снова выползло тут", по возможности пополняя тот самый контекст. Как только комментариев становится больше трёх, возвращаем "нормальный" приоритет и задача как правило захватывается в следующем спринте, если нет чего-то прям нереально горящего.
Аргумент про "команда не доверяет бэклогу" тоже какой-то натянутый. Сравнительно самостоятельной команде от бэклога нужна линейная сортировка в порядке взятия в работу, кончились задачи - взял одну из 3-5 задач сверху, с которой можешь справиться. Способов реализации такой сортировки полно: очереди (а-ля месяц-квартал-год-потом), матрица Эйзенхауэра, ручками, случайно перемешивая, просто по приоритету, по (про)сроку итд. Если сверху ещё и фильтры накинуть (специализация работника + незаблокированные ничем задачи), вопрос его самостоятельного выбора следующей задачи при исчерпании задач в спринте - выеденного яйца не стоит.
Вот если заведённые сотрудником задачи удаляют - это как раз отличный повод перестать доверять бэклогу, как ненадёжному хранилищу, а также в случае с категорией задач, описанной выше, перестать их откладывать и хвататься за всё и сразу, забивая на приоритеты и текущую задачу.
Возможно, наши мнения не конфликтуют - если вы имеете в виду осознанную отмену задачи её же автором, я целиком согласен. Видишь, что не делается и впереди туча других задач - тогда отмена вполне легальна.
Меня изрядно вкорёжило в статье:
В смысле, блин, устарел? Почему браузер за меня будет решать что скачиваемый мной файл устарел?
У меня есть пример, когда осмысленно не закрывал файлы. Это утилиты, единственная задача которых - обработать файл. Контекстный менеджер в таком случае уже существует и называется "процесс операционной системы". Завершается он - закрываются и все его файлы :)
Часть не современные.
Часть не развитые.
Часть не может.
Часть не хочет.
К чему грести всех под одну единственную причину?
Не верю я, что на дистанционке вопрос количества подключающихся удалённо имеет бутылочное горлышко в виде локальной беспроводной сети.
Стало интересно, насколько нелинейна формула и сколько часов выдаст 1 час тренировок 1, 2 или 3 раза в неделю. Или 30 минут 6 раз в неделю. В упор не нашёл числа 0,010677 в статье, которую цитируете в конце. Запятую как разделитель на точку менял. Точность сокращал. Можете ткнуть носом, с какой страницы вы это взяли?
Глянул на отчёт, но не смог правильно истолковать методологию работы с источниками данных. Испытываю подозрение, что часть айтишников, ворвавшись в айтишную ипотеку, как в способ сбережения средств, сдают теперь эту недвижку вбелую, оформившись как самозанятые, ибо это дешевле, чем НДФЛ и ИП. При этом статус самозанятого не отменяет трудовую деятельность в найме. Сам сдаю так, плачу на текущий момент 3%, т.к. оказываю услугу физикам и пока есть налоговый бонус (1%, 10 000₽). Из коробки есть онлайн-чеки, можно заявлять доход не делясь данными об этом с банками.
Я обычный русский айтишник, никакой миска рис за комментарий.В жизни не встречал соседа по имени Купер. Надо было назвать "Васян"
А я люблю есть куда-то.
Привязка карты и переход в приложение банка для оплаты - это несколько разные подходы с разным уровнем доверия к продавцу. Лично мне второй предпочтительнее, разбрасываться реквизитами карты на формах, пусть и с красивой PNG'шкой PCI-DSS, не хочется.
Ну суть мысли-то не меняется, почему
знаменитостистудии не оседлали эту волну?)От себя добавлю просто пример про стабильный интерес.
Я недавно ремонт делал и заморочился за локальное и понятное мне (тупое и примитивное) управление всеми относительно умными устройствами, которые у меня есть. Поскольку их зоопарк (где-то 4 вендора), нужно было что-то однообразное и пока это MQTT.
Помимо MQTT у всех есть свои приложения, в которых по-разному неудобная логика - где-то максимум три правила в расписании, где-то расписание игнорит то, что я 1 минуту назад прибор выключил, потому что он мне мешает и снова его включает, где-то ещё что-то. Расстраивает водонагреватель от Electrolux, который отучить от облака у меня пока никак не получается.
Можно было бы это всё в Home Assistant засунуть, но мне хотелось тупой дом, поэтому я накостылял где-то 450 строчек (из которых около 100 - правила на самопальной структуре в YAML) свой велосипед и сижу довольный. Если бы мне для одного вендора пришлось бы CoAP тащить, для другого Thread, я бы сильно расстроился :)
И вот имея такой велосипед на руках я стою перед вторым ремонтом в доме и уже понимаю, что буду на всю технику смотреть сильно внимательнее и то, что работать в режиме локального MQTT не умеет - тупо не куплю.
Отчего же бестолку. Было бы желание - а толк найдётся. На тестовом слое можно выполнить выдернутый из логов запрос, а уж наполнение базы тестового слоя приближенными к реальности объёмами - это другой вопрос. Во всяком случае это будет лучше чем (в порядке уменьшения лучшести):
ничего
просто SQL-запрос
Explain с локалхоста вообще без данных
Ясно.
Explain прикладывать надо, а не SQL :)
Аж захотел написать "зеркальную" статью с диаметрально противоположными тезисами с точки зрения тех самых сотрудников, которые ищут причины почему что-то не сработает. Не просто ведь так они это делают?
Тоже на 740 синхронизация (приём книжек по почте) отвалилась без объяснения причин (просто пишет "Ошибка синхронизации") в итоге от Wi-Fi уже никакого смысла и не осталось. Ладно хоть по кабелю скидывать книги пока не запрещают.
Осталось для пешеходов что-то придумать.
Так в прошлом-то переключатели были огого, а в будущем будут хехехе.
Интересно, часто ли ставят в качестве пин-кода один из четырёхнаборов цифр из номера карты?
Очень сомнительный аргумент про "если задача нужна, её заведут снова с новым контекстом". То есть мы получим а) дубль, б) потеряв половину контекста.
Я в целом вижу категорию задач - выпрямить какой-то косяк в системе, который приводит к периодическому ручному труду. Если бросаться сразу всё автоматизировать - задачи с большим выхлопом пострадают, если ничего не записывать (и не делать периодически) - система обрастает такими "ручниками". Я с ними работаю следующим образом - записываю с низким приоритетом и потом каждый раз, когда занимаюсь таким "ручником" и это бесит - добавляю комментарий "снова выползло тут", по возможности пополняя тот самый контекст. Как только комментариев становится больше трёх, возвращаем "нормальный" приоритет и задача как правило захватывается в следующем спринте, если нет чего-то прям нереально горящего.
Аргумент про "команда не доверяет бэклогу" тоже какой-то натянутый. Сравнительно самостоятельной команде от бэклога нужна линейная сортировка в порядке взятия в работу, кончились задачи - взял одну из 3-5 задач сверху, с которой можешь справиться. Способов реализации такой сортировки полно: очереди (а-ля месяц-квартал-год-потом), матрица Эйзенхауэра, ручками, случайно перемешивая, просто по приоритету, по (про)сроку итд. Если сверху ещё и фильтры накинуть (специализация работника + незаблокированные ничем задачи), вопрос его самостоятельного выбора следующей задачи при исчерпании задач в спринте - выеденного яйца не стоит.
Вот если заведённые сотрудником задачи удаляют - это как раз отличный повод перестать доверять бэклогу, как ненадёжному хранилищу, а также в случае с категорией задач, описанной выше, перестать их откладывать и хвататься за всё и сразу, забивая на приоритеты и текущую задачу.
Возможно, наши мнения не конфликтуют - если вы имеете в виду осознанную отмену задачи её же автором, я целиком согласен. Видишь, что не делается и впереди туча других задач - тогда отмена вполне легальна.