Заметил, что без малейшего размышления закрываю все всплывающие окна в приложениях, когда есть намерение попасть на какой-то конкретный экран или что-то сделать. Иногда даже потом интересно, что там было, но действие дошло до автоматизма. А подрастающее поколение и вовсе обучается кликать на "крестик" чуть ли не раньше, чем говорить. Похоже, тут нужен пересмотр UX. Наверняка что-то более удачное можно придумать!
Для истории - клиппер, который выпустил Obsidian, очень облегчил процесс, буквально до 1 клика (и последующей сортировки по папкам). Картинки все еще ссылками, но меня греет мысль, что даже если например статью на Хабре закроет автор, то он скорее всего не пойдет удалять файлы из хабрастораджа (возможно и нельзя это делать).
Присоединяюсь к вопросу @numb. Непонятно, почему роман с обилием воды и свойственными жанру метафорами показался лучше и полезнее, чем дистилированный материал с конкретными советами, основными на исследовании с разобранной методикой измерения. Я лично считаю, что обе книжки по-своему хороши, каждая в своих ситуациях, язык не поворачивается назвать какую-то из них мусором.
Постараюсь позднее добавить FAR к сравнению. Честно признаться, думал он исключительно под linux работает, поэтому рассмотрел только MC из консольных файловых менеджеров.
Буду признателен, если поделитесь своим опытом: как-то кастомизируете или берете вариант "из коробки", какие просмотрщик/редактор используете и настраивается ли это, во всех ли сценариях ищете в фаре или дополняете другими инструментами.
Соглашусь, что IDE это отличный вариант, который просто работает и в среднем не заставляет задумываться об использовании дополнительных инструментов. Если же по той или иной причине есть необходимость в каком-то из следующих аспектов:
Практически нулевая скорость запуска и затраты оперативной памяти
Компактный консольный UI, который можно запустить в терминале
TL;DR: рекомендую выставить ширину таба в дереве в 18-20 пикселей: "workbench.tree.indent": 20
Мои 5 копеек не про плагины. Долгое время не мог понять, почему визуально плохо ориентируюсь по дереву, когда много файлов/папок открыто. Оказалось, что этому очень мешает дефолтная ширина отступа в 8 пикселей. Позже просто увеличил этот отступ, теперь структура гораздо приятнее для восприятия. Это единственная опция, которую я трогаю в свежей установке VS Code, все остальное и так неплохо выглядит и работает.
Как грустно, видимо у кого-то во время появления Itanium было большое обновление оборудования и софта, перешли на самую новую архитектуру, были впереди индустрии, но кто же знал что архитектура загнётся... Получается что они залочены на мертвой архитектуре, но линукс могут получать относительно свежий. Есть ли от этого профит? Звучит как откладывание неизбежного.
Такое ощущение, что статья целиком сгенерирована ChaGPT: все тезисы изложены буллитами, а говорится в них обо всем и ни от чем одновременно. Ценность под вопросом.
Немного оффтоп: в хабах указан Go, разве Джеффри Рихтер имеет какое-то отношение к этому языку? В сообществе Windows и .NET у него огромный вес (фигурально), в контексте Go-разработки не встречал каких-то работ
Отсюда следует интересный результат: поскольку listcomp — это функция, у нас возникают постоянные расходы на ее вызов. т. е. на небольших объемах данных списковые включения должны уступать в производительности циклу for
Функция вроде один раз вызывается, и за один вызов полностью строит список. Причем добавление элементов в список так же происходит в цикле, но делается не через вызов функции append, а специальной командой LIST_APPEND.
Я внутрянку Python не особо внимательно изучал, могу ошибаться, но листинг байткода читается так.
По опыту: протеиновый коктейль в шейкере и в блендере разный уровень сытости даёт. В первом случае минимально размешивается, во втором взбивается до пены. Похоже что пузырьки реально работают.
По зелени трудно сказать, я её совсем не чувствую, или например гречка вареная по объему вроде приличная, а через полчаса уже есть хочется.
Тоже бросилось в глаза. Очень "роботизированные" движения были, даже принимая во внимание строгий протокол испытаний. Там пара моментов была, когда всего космонавта разворачивать начало, а рука не дернулась.
V скорее про убийство Go)
Заметил, что без малейшего размышления закрываю все всплывающие окна в приложениях, когда есть намерение попасть на какой-то конкретный экран или что-то сделать. Иногда даже потом интересно, что там было, но действие дошло до автоматизма. А подрастающее поколение и вовсе обучается кликать на "крестик" чуть ли не раньше, чем говорить. Похоже, тут нужен пересмотр UX. Наверняка что-то более удачное можно придумать!
Для истории - клиппер, который выпустил Obsidian, очень облегчил процесс, буквально до 1 клика (и последующей сортировки по папкам). Картинки все еще ссылками, но меня греет мысль, что даже если например статью на Хабре закроет автор, то он скорее всего не пойдет удалять файлы из хабрастораджа (возможно и нельзя это делать).
Похоже на просто "хук", без "веб", если речь про файл в .git/hooks, как можно предположить по содержимому
Мне кажется, Вы боту отвечаете. Сообщение крайне похоже на сгенерированное нейронкой.
Присоединяюсь к вопросу @numb. Непонятно, почему роман с обилием воды и свойственными жанру метафорами показался лучше и полезнее, чем дистилированный материал с конкретными советами, основными на исследовании с разобранной методикой измерения. Я лично считаю, что обе книжки по-своему хороши, каждая в своих ситуациях, язык не поворачивается назвать какую-то из них мусором.
Постараюсь позднее добавить FAR к сравнению. Честно признаться, думал он исключительно под linux работает, поэтому рассмотрел только MC из консольных файловых менеджеров.
Буду признателен, если поделитесь своим опытом: как-то кастомизируете или берете вариант "из коробки", какие просмотрщик/редактор используете и настраивается ли это, во всех ли сценариях ищете в фаре или дополняете другими инструментами.
Соглашусь, что IDE это отличный вариант, который просто работает и в среднем не заставляет задумываться об использовании дополнительных инструментов. Если же по той или иной причине есть необходимость в каком-то из следующих аспектов:
Практически нулевая скорость запуска и затраты оперативной памяти
Компактный консольный UI, который можно запустить в терминале
Приближенная к максимальному скорость поиска
Возможность кастомизировать и скриптовать действия
Минимализм "дистрибутива"
Свободная лицензия и бесплатность
То можно посмотреть в сторону рассмотренного поисковика.
Просто не надо было изначально делать логику такого характера на QML, особенно с использованием таймеров.
TL;DR: рекомендую выставить ширину таба в дереве в 18-20 пикселей: "workbench.tree.indent": 20
Мои 5 копеек не про плагины. Долгое время не мог понять, почему визуально плохо ориентируюсь по дереву, когда много файлов/папок открыто. Оказалось, что этому очень мешает дефолтная ширина отступа в 8 пикселей. Позже просто увеличил этот отступ, теперь структура гораздо приятнее для восприятия. Это единственная опция, которую я трогаю в свежей установке VS Code, все остальное и так неплохо выглядит и работает.
Зашёл в комментарии проверить, что кто-то вспомнил и про виртуализацию. Отлично, Хабр настороже 🫡
Как грустно, видимо у кого-то во время появления Itanium было большое обновление оборудования и софта, перешли на самую новую архитектуру, были впереди индустрии, но кто же знал что архитектура загнётся... Получается что они залочены на мертвой архитектуре, но линукс могут получать относительно свежий. Есть ли от этого профит? Звучит как откладывание неизбежного.
Такое ощущение, что статья целиком сгенерирована ChaGPT: все тезисы изложены буллитами, а говорится в них обо всем и ни от чем одновременно. Ценность под вопросом.
От авторов "C++ за 21 день"? 😄
Чудеса! Тогда, собственно, возникает вопрос: что сподвигло уйти из мира .NET и почему именно Go?
Немного оффтоп: в хабах указан Go, разве Джеффри Рихтер имеет какое-то отношение к этому языку? В сообществе Windows и .NET у него огромный вес (фигурально), в контексте Go-разработки не встречал каких-то работ
Стоит упомянуть про то, что массивы по семантике ближе к значениям, а слайсы к ссылкам. На практике это заметно в кейсах:
Передача в функцию - массивы копируются
Сравнение - массивы можно сравнивать через оператор ==
for-range - массивы неизменяемы в таком цикле из-за неявного копирования
Функция вроде один раз вызывается, и за один вызов полностью строит список. Причем добавление элементов в список так же происходит в цикле, но делается не через вызов функции append, а специальной командой LIST_APPEND.
Я внутрянку Python не особо внимательно изучал, могу ошибаться, но листинг байткода читается так.
По опыту: протеиновый коктейль в шейкере и в блендере разный уровень сытости даёт. В первом случае минимально размешивается, во втором взбивается до пены. Похоже что пузырьки реально работают.
По зелени трудно сказать, я её совсем не чувствую, или например гречка вареная по объему вроде приличная, а через полчаса уже есть хочется.
Тоже бросилось в глаза. Очень "роботизированные" движения были, даже принимая во внимание строгий протокол испытаний. Там пара моментов была, когда всего космонавта разворачивать начало, а рука не дернулась.