кстати, неплохо помогает для этого adb. с его помощью удалил или отключил всякий мусор как на телефоне, так и на телевизоре. еще и автоматизировать можно
тут так принято - окна и программа чуть разные сущности в MacOS
ну так пусть так себя ведут все приложения, а то часть - остается висеть , а часть закрываются полностью (системные настройки, App Store и вроде бы Activity viewer). И, вроде бы, это исключительно на усмотрение разработчика, что я считаю глупостью. И хотя адепты скажут, что "так было всегда", я лично я считаю, что использовать прием из интерфейса 1988 года (Mac OS 6) - плохое решение.
Спасибо, я знаю. Да и не напрягает меня это. Я привел это как пример того, что на сертифицированном ноуте у меня возник только этот нюанс, который по большому счету не влияет на работу. И я не говорил, что это баг ноута=) Я это к тому, что на сертифицированных шанс получить отсутствие драйверов на какую-то железку сильно ниже.
Если хочется 2 полноценных SO-DIMM разъема - стоит посмотреть вообще на серию P. (например P14s Gen5). Ну или сразу искать конфигурацию с нужным количеством памяти, да. Я сразу выбрал 32Гб.
Про драйвера - Ubuntu certified laptops. Себе искал именно сертифицированный. И за 5 лет единственный баг - некорректная работа индикатора выключенного микрофона.
Про охлаждение - опять же, стоит обратиться к серии P, у них более массивная система. В своем я менял термопасту на Arctic MX-6. Если потребуется менять еще раз - думаю попробовать Honeywell с фазовым переходом. С жидким металлом я как-то побаиваюсь связываться, но рад, что у вас все получилось.
Про отвал оборудования - согласен, очень похоже на критическую неудачу. На моем за все время использования (как рабочий и личный) приключилась проблема с клавиатурой (начала мерцать подсветка) - по гарантии заменили весь палмрест. У жены на X13 за 4 года проблем не было вообще.
мне VScode для питона - не нравится. intelliSense работает криво с появления и до сих пор. даже в neovim с treesitter лучше и постоянно использую Run Configurations
хотя, возможно, я просто не умею настраивать VScode
Я читаю через RSS с разделением на новости, статьи и посты. И мне очень не хватает возможности поместить хаб или автора в черный список, так, чтобы даже если статья как-то пересекается со мной, всеравно не показывалась в ленте. Настолько не хватает, что пришлось городить проксю для RSS , который это делает, посколько в RSS фид отдаются тэги, а не хабы. Что, кстати, тоже для меня не удобно.
У меня - Xreal one (не Pro). Брал в первую очередь для Steam Deck.
Высказывания, типа "191 дюйм" - маркетинговый булшит (тем более, что в настройках можно выставить все 300). В настройках можно менять виртуальное расстояние до "экрана" и собственно размер этого "экрана". Грубо говоря, 300 на 6 метрах и 150 на 3 - примерно одно и то же.
По режимам: для меня самый оптимальный - плавное следование и экран чуть меньше максимума, чтобы не обрезались края при движении головы.
В связке со Steam Deck - удобно. А в дороге - хорошо. Смотреть фильмы или играть - комфортно. При максимальной яркости - потребление около 2 Вт (но мне было уже не комфортно, я использую около 40-50%). Поскольку встроенный экран отключается, автономность падает совсем не сильно.
Как экран для ПК - пробовал, восторгов не испытал. Текст читаемый, цветопередача/контраст - нормальные, но не то.
В целом, я покупкой доволен. В моих сценариях работает хорошо. Но, чтобы не разочароваться в покупке, нужно четко понимать, зачем это вам и какие сценарии использования будут.
Спасибо, достаточно приятный инструмент. Но сразу возникло несколько замечаний/предложений:
не поддерживаются VIM сочетания, особенно удивился, что не работают /, G и gg, при условии, что они даже в journalctl работают. Так же в lazydocker и lazygit они работают, поэтому тут я немного потерялся.
по ? было бы хорошо открыть подсказку по сочетаниям клавиш. И, как вариант, снизу показывать базовые клавиши.
если вам не нравится/не удобно использовать VIM сочетания, можно попробовать дать возможность настраивать клавиши через ~/.config/lazyjournal/lazyjournalrc
А то как-то странно получается - вроде бы lazy-, но управление не как в других утилитах.
Anyway, спасибо, с интересом буду следить за проектом!=)
в случае с DataPoint со слотами получилось 15236.9 KiB, без слотов - 19136.7 KiB. выиграли около 25%. Размер объекта с __slots__: 56 байт Полный размер объекта без __slots__ (включая __dict__): 367 байт Разница: 311 байт на объект вот тут выигрыш в 7 раз
Я выстроил себе такую систему: Obsidian на десктопе + на телефоне. Синхронизация через syncthing через отдельный сервер (в облаке). По крону с сервера раз в сутки коммичу и заливаю все в гитхаб.
Сервер - источник правды. Позволяет обходить необходимость держать оба устройства online, чтобы они могли синхронизироваться.
js в templates - не самое хорошее решение. для этого есть static.
Django-приложения в modules. зачем modules? при условии, что в корне проекта будет app, modules, templates и manage.py, создание дополнительного неймспейса, кажется, не дает никакого выйгрыша.
app в названии приложений.
Про HTMX уже говорили. Я согласен, что он был бы тут очень кстати. Но, как вариант, можно рассмотреть Alpine Ajax
еще как вариант использовать django-render-block, чтобы было удобнее работать с htmx/alpine
Если работать с сервером, то иногда требуются дополнительные настройки, современные функци, идующие с fetch, и ещё плюшки работы с javascript и DOM деревом
Например?
Я не говорю, что HTMX должен заменить библиотеки и фреймворки. Я считаю, что разные инструменты нужны для разных вещей. Для минимального манипулирования DOM яв предпочитаю использовать hyperscript (от автора HTMX и неплохой интеграции с ним) или alpineJS.
Текущий подход с отдельным бэком и фронтом на React/Vue/Angular/Svelte/etc... позволяет более гибко управлять командами, разделяя ответственность, строя независимые циклы релизов и прочее. Но у этого есть цена - переусложнение (отдельный пайплайн сборки фронта, отдельные настройки для SSR, backend-for-frontend простихоспади), проблема синхронизации и передачи состояний (раньше состояние хранилось и управлялось на бэке). И некоторые функции в текущих фреймворках выглядят как решения проблем, которые были искусственно созданы. Ну и порой неадекватный размер фронтовых бандлов - туда же.
Для того, чтобы отобразить просто список статей/статью, табличку, обработать форму - вовсе не обязательно строить второе приложение. Это, само собой, не касается приложений, которые полностью работают на фронте (тот же draw.io, google docs, всякие игры и прочее). Если правильно разбить html на бэке (на переиспользуемые компоненты) - работа с htmx не доставляет головной боли=)
При этом, в случае с HMPL - если я правильно понял, это все равно отдельный JS файл (или файлы), который с нуля строит страницу. Концептуально, он выглядит более похожим на фреймворки большой тройки. И получается вообще все будет в бандле, даже элементы страниц, которые на данный момент не нужны. Понятно, что можно как-то настроить бандлер и подгрузку модулей, чтобы грузилось только то, что нужно на текущий момент, но это не просто и выглядит как решение выдуманной проблемы.
кстати, неплохо помогает для этого adb. с его помощью удалил или отключил всякий мусор как на телефоне, так и на телевизоре. еще и автоматизировать можно
а в RSS вообще все подряд валится (полностью игнорируется, на что подписан, на что - нет). зато объяснялка кода появилась, чо
ну так пусть так себя ведут все приложения, а то часть - остается висеть , а часть закрываются полностью (системные настройки, App Store и вроде бы Activity viewer). И, вроде бы, это исключительно на усмотрение разработчика, что я считаю глупостью. И хотя адепты скажут, что "так было всегда", я лично я считаю, что использовать прием из интерфейса 1988 года (Mac OS 6) - плохое решение.
Помимо всех остальных несостыковок, на двух фотографиях с телефоном в руках, хотя утверждает, что не пользуется телефоном.
Хоть я и пользуюсь телегой, я не доверяю Дурову, ни как человеку, ни как владельцу бизнеса.
На вторичном рынке цена более менее адекватная, а автор, как я понял, тоже брал не новый.
Спасибо, я знаю. Да и не напрягает меня это. Я привел это как пример того, что на сертифицированном ноуте у меня возник только этот нюанс, который по большому счету не влияет на работу. И я не говорил, что это баг ноута=)
Я это к тому, что на сертифицированных шанс получить отсутствие драйверов на какую-то железку сильно ниже.
Дополню:
Если хочется 2 полноценных SO-DIMM разъема - стоит посмотреть вообще на серию P. (например P14s Gen5). Ну или сразу искать конфигурацию с нужным количеством памяти, да. Я сразу выбрал 32Гб.
Про драйвера - Ubuntu certified laptops. Себе искал именно сертифицированный. И за 5 лет единственный баг - некорректная работа индикатора выключенного микрофона.
Про охлаждение - опять же, стоит обратиться к серии P, у них более массивная система. В своем я менял термопасту на Arctic MX-6. Если потребуется менять еще раз - думаю попробовать Honeywell с фазовым переходом. С жидким металлом я как-то побаиваюсь связываться, но рад, что у вас все получилось.
Про отвал оборудования - согласен, очень похоже на критическую неудачу. На моем за все время использования (как рабочий и личный) приключилась проблема с клавиатурой (начала мерцать подсветка) - по гарантии заменили весь палмрест. У жены на X13 за 4 года проблем не было вообще.
FerretDB быстрее в 5-20 раз чем что?
единственное сравнение, которое я нашел - на reddit но есть большие сомнения касаемо методики тестирования, однако там Ferret показал себя не с лучшей стороны - во всех случаях использование Postgres с JSONB полями оказалось быстрее. И при этом, Mongo обвиняет Ferret в присвоении интеллектуальной собственности и нарушении патентов
Лично я бы пока поостерегся использовать ее
мне VScode для питона - не нравится. intelliSense работает криво с появления и до сих пор. даже в neovim с treesitter лучше
и постоянно использую Run Configurations
хотя, возможно, я просто не умею настраивать VScode
Я читаю через RSS с разделением на новости, статьи и посты.
И мне очень не хватает возможности поместить хаб или автора в черный список, так, чтобы даже если статья как-то пересекается со мной, всеравно не показывалась в ленте.
Настолько не хватает, что пришлось городить проксю для RSS , который это делает, посколько в RSS фид отдаются тэги, а не хабы. Что, кстати, тоже для меня не удобно.
У меня - Xreal one (не Pro). Брал в первую очередь для Steam Deck.
Высказывания, типа "191 дюйм" - маркетинговый булшит (тем более, что в настройках можно выставить все 300). В настройках можно менять виртуальное расстояние до "экрана" и собственно размер этого "экрана". Грубо говоря, 300 на 6 метрах и 150 на 3 - примерно одно и то же.
По режимам: для меня самый оптимальный - плавное следование и экран чуть меньше максимума, чтобы не обрезались края при движении головы.
В связке со Steam Deck - удобно. А в дороге - хорошо. Смотреть фильмы или играть - комфортно. При максимальной яркости - потребление около 2 Вт (но мне было уже не комфортно, я использую около 40-50%). Поскольку встроенный экран отключается, автономность падает совсем не сильно.
Как экран для ПК - пробовал, восторгов не испытал. Текст читаемый, цветопередача/контраст - нормальные, но не то.
В целом, я покупкой доволен. В моих сценариях работает хорошо. Но, чтобы не разочароваться в покупке, нужно четко понимать, зачем это вам и какие сценарии использования будут.
Простите, у них цены от 150$ за HD (720p!) экранчик. Спасибо, что хотя бы IPS.
За такие деньги требовать еще что-то сверху - как-то совсем по-свински.
да, конечно. но надо немного попользоваться, чтобы понять где чего не хватает.
Спасибо, достаточно приятный инструмент.
Но сразу возникло несколько замечаний/предложений:
не поддерживаются VIM сочетания, особенно удивился, что не работают
/,Gиgg, при условии, что они даже в journalctl работают. Так же вlazydockerиlazygitони работают, поэтому тут я немного потерялся.по
?было бы хорошо открыть подсказку по сочетаниям клавиш. И, как вариант, снизу показывать базовые клавиши.если вам не нравится/не удобно использовать VIM сочетания, можно попробовать дать возможность настраивать клавиши через
~/.config/lazyjournal/lazyjournalrcА то как-то странно получается - вроде бы
lazy-, но управление не как в других утилитах.Anyway, спасибо, с интересом буду следить за проектом!=)
в случае с
DataPointсо слотами получилось 15236.9 KiB, без слотов - 19136.7 KiB. выиграли около 25%.Размер объекта с
__slots__: 56 байтПолный размер объекта без
__slots__(включая__dict__): 367 байтРазница: 311 байт на объект
вот тут выигрыш в 7 раз
Для Arch 3 версия в Extra-Testing, думаю, скоро будет в основной репе.
А на Flathub уже общедоступна тройка. У меня FH версия - уже все обновилось и прекрасно работает=)
Flatpak пакет уже зарелизили
Я выстроил себе такую систему: Obsidian на десктопе + на телефоне. Синхронизация через syncthing через отдельный сервер (в облаке). По крону с сервера раз в сутки коммичу и заливаю все в гитхаб.
Сервер - источник правды. Позволяет обходить необходимость держать оба устройства online, чтобы они могли синхронизироваться.
js в
templates- не самое хорошее решение. для этого естьstatic.Django-приложения в
modules. зачемmodules? при условии, что в корне проекта будетapp,modules,templatesиmanage.py, создание дополнительного неймспейса, кажется, не дает никакого выйгрыша.appв названии приложений.Про HTMX уже говорили. Я согласен, что он был бы тут очень кстати. Но, как вариант, можно рассмотреть Alpine Ajax
еще как вариант использовать django-render-block, чтобы было удобнее работать с htmx/alpine
Например?
Я не говорю, что HTMX должен заменить библиотеки и фреймворки. Я считаю, что разные инструменты нужны для разных вещей. Для минимального манипулирования DOM яв предпочитаю использовать hyperscript (от автора HTMX и неплохой интеграции с ним) или alpineJS.
Текущий подход с отдельным бэком и фронтом на React/Vue/Angular/Svelte/etc... позволяет более гибко управлять командами, разделяя ответственность, строя независимые циклы релизов и прочее. Но у этого есть цена - переусложнение (отдельный пайплайн сборки фронта, отдельные настройки для SSR, backend-for-frontend простихоспади), проблема синхронизации и передачи состояний (раньше состояние хранилось и управлялось на бэке). И некоторые функции в текущих фреймворках выглядят как решения проблем, которые были искусственно созданы. Ну и порой неадекватный размер фронтовых бандлов - туда же.
Для того, чтобы отобразить просто список статей/статью, табличку, обработать форму - вовсе не обязательно строить второе приложение.
Это, само собой, не касается приложений, которые полностью работают на фронте (тот же draw.io, google docs, всякие игры и прочее).
Если правильно разбить html на бэке (на переиспользуемые компоненты) - работа с htmx не доставляет головной боли=)
При этом, в случае с HMPL - если я правильно понял, это все равно отдельный JS файл (или файлы), который с нуля строит страницу. Концептуально, он выглядит более похожим на фреймворки большой тройки. И получается вообще все будет в бандле, даже элементы страниц, которые на данный момент не нужны. Понятно, что можно как-то настроить бандлер и подгрузку модулей, чтобы грузилось только то, что нужно на текущий момент, но это не просто и выглядит как решение выдуманной проблемы.
В целом, я категорически не согласен с мыслью: