Про Steam:
Помимо виш-листа у них есть ещё и «персонализированная» главная страница.
Вот там полный Пузырь фильтров.
Стим продолжает показывать мне одни и те же игры — что-то недостаточно интересное (иначе бы уже купил), недостаточно отвратное (не хочу добавлять в игнор-лист), и при этом максимально популярное среди всех пользователей (мнение которых «очень важно для нас»). В общем, практически статичная страница с играми, не вызывающими у меня никакого отклика.
Кажется, простое примешивание случайных игр повысило бы вероятность найти что-то интересное. В худшем случае просто добавлю в игнор-лист (в копилку данных для рекомендательной системы, которой нет...)
Но, «что за дикость, где это видано», чтобы пользователю отдавались не оптимизированные «персонально под него» результаты?!
Вы можете использовать Node.js-приложения на хостинге через SSH-консоль.
Так-то и Python3 у вас как-бы есть. Речь про веб.
Про VDS, дарю идею:
Автоматизируйте миграцию с шаред-хостинга. Чтобы все проекты на моём аккаунте продолжили работать как ни в чём не бывало. И без привязки к какому-нибудь платному ISPmanager. Тогда перееду, может быть.
Держать и шаред и VDS считаю неоправданным в моём случае.
О работах на сервере и планируемой кратковременной недоступности вы оповещаете заранее. Забыли о чём-то оповестить и рассказать сделанных выводах, если это ЧП — добавили в копилку недовольства.
В данном случае что-то похожее на плашку предупреждения я увидел только в Файловом Менеджере. В остальных случаях — заглушка браузера о недоступной странице.
Даже если не хочется о работах по панели оповещать через почту больше народу, чем имеет риск столкнуться с ними — при входе в панель я должен был получить представление об объёмах и сроке ограничений.
Меня, как пользователя шаред-хостинга, Timeweb разочаровывает.
Сравнительно дорого. При этом поддержку Python3 вот только-только запланировали. Про Node вообще молчу. Зато регулярные попытки впарить Битрикс.
Прямо сейчас без предупреждения ограничен доступ к половине контрольной панели.
Нужно различать «сеть поверх XMPP» и «сеть с интерфейсом через бота».
Все перечисленные относятся ко второму типу.
Интерфейс через бота, в целом, имеет право на существование. Однако есть несколько моментов:
1. XMPP здесь на равных правах или меньше (но не больше) с другими сетями обмена сообщений в плане технических возможностей для бота. Везде, где можно передавать plain text — можно устроить ботов с командами. Однако можно видеть, что другие мессенджеры могут предоставлять больше возможностей для ботов.
Хотите кнопки в интерфейсе, которые будут работать в любом клиенте? — это не про XMPP.
Есть XEP для кнопок? — см. про «XEP сам себя не реализует».
Честный счётчик непрочитанных сообщений? Лайки/реакции? — пишите свой клиент.
2. Популярность. Мало кто продолжает использовать XMPP ради одного лишь Juick'а. Диверсификация с добавлением бота в Телеграм была воспринята весьма позитивно. В целом, Juick, Point и BnW вместе взятые сейчас генерируют заметно меньше контента, чем один лишь Juick в момент своего рассвета. И существуют разве что по инерции, за счёт ранее набранной аудитории.
(На самом деле, технически, до недавнего времени Juick можно было назвать «сетью поверх XMPP». Однако это создавало только проблемы. Хотя я не во всём поддерживаю вектор развития Juick'а сейчас, вынос XMPP из архитектуры и оставление только в качестве интерфейса — это однозначно улучшение.)
Никто не заставляет собирать, то что считаете не нужным.
Это смешно в условиях, когда даже на нужное времени не хватает. Однако разные привычные и нужные фичи вдруг плохо ведут себя в новых условиях.
Всегда можно дописать новое, а не использовать то что ненравится.
Это упирается в поддержку клиентов и серверов.
Какой прок от расширений, которые никто не поддерживает?
Если забить на весь остальной мир, то проще делать свою реализацию без XMPP.
Если пытаться тянуть остальной мир за собой, то нужно вкладываться в работу над XEP, а потом ещё и реализовывать его самостоятельно в клиентах и серверах. XEP сам себя не реализует, поскольку у базара нет единой движущей силы.
Movim — веб-клиент и заодно социальная сеть на основе XMPP
В итоге слабый клиент и слабая социальная сеть.
Понаблюдав немного за кухней, я пришёл к выводу, что там проблемы двух видов:
1. не хватает рук или скиллов у одного человека;
2. сложности со спецификациями.
Идеальный мир: определяемся с набором фич, смотрим как их наиболее логично совместить и с наименьшими усилиями реализовать.
Реальность: попытка натянуть сову на глобус, в условиях когда есть куча пересекающихся но неполных и местами взаимоисключающих спецификаций, не имеющих эталонной реализации. Попытка собрать разрозненные концепты в единое целое напоминает монстра Франкенштейна, абстракции ломаются в неожиданных местах, и невозможно достичь логичного, казалось бы, поведения.
Как отметил сам разработчик, было бы неплохо, если бы на его работу обратили внимание те, кто пишут XEPы (теорию к реальности подтянуть). Однако я не уверен, что даже он сам знает, как развивать проект.
Раз уж Movim упомянут:
Когда начинаешь пытаться его использовать — понимаешь, что он представляет из себя довольно печальное зрелище.
Социальная сеть поверх XMPP — довольно шаткая и ограниченная конструкция. Вероятность того, что какой-то из популярных клиентов полезет в те же дебри — нулевая. А без этого XMPP скорее тянет проект ко дну, чем помогает.
Я какое-то время использовал SourceTree параллельно с GitHub Desktop.
В гитхабовом клиенте, пожалуй, самый удобный split commit.
Но в итоге, устав от разных других недостатков обоих клиентов, перешёл на GitKraken.
Самый продуманный клиент git под Windows. Впервые после TortoiseHg не страшно за каждый шаг, и всё как на ладони.
Split commit тут вполне сносный (показывает изменения чанками, но строки тоже можно выделять).
Из недостатков — запускается долго и тот же выбор строк в стедж подтормаживает на больших файлах. Ну и free for personal use только.
В VSCode тоже теперь можно построчно стейджить изменения. Если бы не GitKraken, на данный момент предпочёл бы VScode + GitLens другим клиентам.
А может быть имелся в виду en.wikipedia.org/wiki/Stippling
Хотя, если бы автор не фокусировался так на дизеринге и low-res, а именно пытался сделать хороший стиплинг, то результат мог бы быть лучше.
Давно мечтаю о «живых» сессиях. Чтобы у каждой сессии было своё окно, и открытие/закрытие вкладок автоматом сохранялось. Чтобы к любой момент можно было открыть/закрыть любой набор сессий и не беспокоиться о том, что что-то где-то забыл сохранить…
Image Properties работает слишком медленно.
Приходится ждать пока он exif прочитает, гистограмму просчитает… — хотя мне всего-то и нужно что размеры картинки узнать.
Нужно по мере вычисления параметры выдавать — важное быстрее, остальное по мере готовности.
Новая панель потенциально удобнее, чем панель табов в положении слева. (Особенно что касается tab stacking). Но очень не хватает нормального визуального фидбэка — на мышь не реагирует практически, различить активную вкладку в тёмных темах почти невозможно.
Плюс, возможно не стоит подсвечивать выбранные вкладки, если панель не в фокусе — это ещё больше сбивает с толку.
Искал, как в настройках Window Panel отключить крестики — оказалось что нужно отключить их в настройках табов. Хорошо что хоть так работает, плохо что не супер очевидно.
Не хватает предупреждения при попытке закрыть группу вкладок, поэтому страшно не в тот крестик попасть.
Menu Position — Horizontal Menu. Нажимая на Window ожидаешь выпадающий список, а браузер вместо этого сразу в полноэкранный режим переключается. Даже если там всего один пункт в подменю, нельзя так делать.
Тема, которая использует #FFFFFF (белый) для текста на тёмном фоне — плохая тема.
При правильно подобранной яркости не должны глаза уставать.
Вот, можно поэкспериментировать.
Заодно добавил расчёт контрастности. В рекомендации есть ограничение снизу, однако на тёмных темах ещё и ограничение сверху бы не помешало. Больше 10 мне уже некомфортно.
Корзина удобна, когда надо вернуть только что закрытую вкладку. Если после этого ещё 22 вкладки закрыть — дальше только в истории искать. А там это может быть тяжело — выше я объяснил почему.
Хочется устранить этот разрыв, и видеть историю в том порядке, в котором видел страницы я.
Вы выбрали самый несущественный момент из комментария и проигнорировали остальное?
Я говорю, что хочу сортировку истории по дате последнего доступа (или закрытия, но подозреваю, что есть ситуации, когда вкладка может потеряться без попадания даты закрытия в историю).
Наиболее логичное решение (возможно, не самое простое, учитывая, что внутри Хромиум) — добавить дополнительные колонки в историю — дата последнего доступа или дата закрытия или обе сразу.
Помимо виш-листа у них есть ещё и «персонализированная» главная страница.
Вот там полный Пузырь фильтров.
Стим продолжает показывать мне одни и те же игры — что-то недостаточно интересное (иначе бы уже купил), недостаточно отвратное (не хочу добавлять в игнор-лист), и при этом максимально популярное среди всех пользователей (мнение которых «очень важно для нас»). В общем, практически статичная страница с играми, не вызывающими у меня никакого отклика.
Кажется, простое примешивание случайных игр повысило бы вероятность найти что-то интересное. В худшем случае просто добавлю в игнор-лист (в копилку данных для рекомендательной системы, которой нет...)
Но, «что за дикость, где это видано», чтобы пользователю отдавались не оптимизированные «персонально под него» результаты?!
(Не мог пройти мимо и не упомянуть нетленку от innubis )
Так-то и Python3 у вас как-бы есть. Речь про веб.
Про VDS, дарю идею:
Автоматизируйте миграцию с шаред-хостинга. Чтобы все проекты на моём аккаунте продолжили работать как ни в чём не бывало. И без привязки к какому-нибудь платному ISPmanager. Тогда перееду, может быть.
Держать и шаред и VDS считаю неоправданным в моём случае.
О работах на сервере и планируемой кратковременной недоступности вы оповещаете заранее. Забыли о чём-то оповестить и рассказать сделанных выводах, если это ЧП — добавили в копилку недовольства.
В данном случае что-то похожее на плашку предупреждения я увидел только в Файловом Менеджере. В остальных случаях — заглушка браузера о недоступной странице.
Даже если не хочется о работах по панели оповещать через почту больше народу, чем имеет риск столкнуться с ними — при входе в панель я должен был получить представление об объёмах и сроке ограничений.
Сравнительно дорого. При этом поддержку Python3 вот только-только запланировали. Про Node вообще молчу. Зато регулярные попытки впарить Битрикс.
Прямо сейчас без предупреждения ограничен доступ к половине контрольной панели.
Все перечисленные относятся ко второму типу.
Интерфейс через бота, в целом, имеет право на существование. Однако есть несколько моментов:
1. XMPP здесь на равных правах или меньше (но не больше) с другими сетями обмена сообщений в плане технических возможностей для бота. Везде, где можно передавать plain text — можно устроить ботов с командами. Однако можно видеть, что другие мессенджеры могут предоставлять больше возможностей для ботов.
Хотите кнопки в интерфейсе, которые будут работать в любом клиенте? — это не про XMPP.
Есть XEP для кнопок? — см. про «XEP сам себя не реализует».
Честный счётчик непрочитанных сообщений? Лайки/реакции? — пишите свой клиент.
2. Популярность. Мало кто продолжает использовать XMPP ради одного лишь Juick'а. Диверсификация с добавлением бота в Телеграм была воспринята весьма позитивно. В целом, Juick, Point и BnW вместе взятые сейчас генерируют заметно меньше контента, чем один лишь Juick в момент своего рассвета. И существуют разве что по инерции, за счёт ранее набранной аудитории.
(На самом деле, технически, до недавнего времени Juick можно было назвать «сетью поверх XMPP». Однако это создавало только проблемы. Хотя я не во всём поддерживаю вектор развития Juick'а сейчас, вынос XMPP из архитектуры и оставление только в качестве интерфейса — это однозначно улучшение.)
Это смешно в условиях, когда даже на нужное времени не хватает. Однако разные привычные и нужные фичи вдруг плохо ведут себя в новых условиях.
Это упирается в поддержку клиентов и серверов.
Какой прок от расширений, которые никто не поддерживает?
Если забить на весь остальной мир, то проще делать свою реализацию без XMPP.
Если пытаться тянуть остальной мир за собой, то нужно вкладываться в работу над XEP, а потом ещё и реализовывать его самостоятельно в клиентах и серверах. XEP сам себя не реализует, поскольку у базара нет единой движущей силы.
(ЗЫ: кажется, на странице Design by committee не хватает ссылки на XMPP.)
В итоге слабый клиент и слабая социальная сеть.
Понаблюдав немного за кухней, я пришёл к выводу, что там проблемы двух видов:
1. не хватает рук или скиллов у одного человека;
2. сложности со спецификациями.
Идеальный мир: определяемся с набором фич, смотрим как их наиболее логично совместить и с наименьшими усилиями реализовать.
Реальность: попытка натянуть сову на глобус, в условиях когда есть куча пересекающихся но неполных и местами взаимоисключающих спецификаций, не имеющих эталонной реализации. Попытка собрать разрозненные концепты в единое целое напоминает монстра Франкенштейна, абстракции ломаются в неожиданных местах, и невозможно достичь логичного, казалось бы, поведения.
Как отметил сам разработчик, было бы неплохо, если бы на его работу обратили внимание те, кто пишут XEPы (теорию к реальности подтянуть). Однако я не уверен, что даже он сам знает, как развивать проект.
Когда начинаешь пытаться его использовать — понимаешь, что он представляет из себя довольно печальное зрелище.
Социальная сеть поверх XMPP — довольно шаткая и ограниченная конструкция. Вероятность того, что какой-то из популярных клиентов полезет в те же дебри — нулевая. А без этого XMPP скорее тянет проект ко дну, чем помогает.
В гитхабовом клиенте, пожалуй, самый удобный split commit.
Но в итоге, устав от разных других недостатков обоих клиентов, перешёл на GitKraken.
Самый продуманный клиент git под Windows. Впервые после TortoiseHg не страшно за каждый шаг, и всё как на ладони.
Split commit тут вполне сносный (показывает изменения чанками, но строки тоже можно выделять).
Из недостатков — запускается долго и тот же выбор строк в стедж подтормаживает на больших файлах. Ну и free for personal use только.
В VSCode тоже теперь можно построчно стейджить изменения. Если бы не GitKraken, на данный момент предпочёл бы VScode + GitLens другим клиентам.
Хотя, если бы автор не фокусировался так на дизеринге и low-res, а именно пытался сделать хороший стиплинг, то результат мог бы быть лучше.
Какие-то работы по теме: www.computer.org/csdl/mags/cg/2003/04/mcg2003040062.html — 2003, real time 3d, не знаю, есть ли что-то такое в открытом доступе и с примерами — просто первое что в гугле попалось.
community.wolfram.com/groups/-/m/t/759091 — алгоритм для статической картинки.
VB-34807
VB-34810
Есть какие-нибудь планы по ним?
Приходится ждать пока он exif прочитает, гистограмму просчитает… — хотя мне всего-то и нужно что размеры картинки узнать.
Нужно по мере вычисления параметры выдавать — важное быстрее, остальное по мере готовности.
Плюс, возможно не стоит подсвечивать выбранные вкладки, если панель не в фокусе — это ещё больше сбивает с толку.
Искал, как в настройках Window Panel отключить крестики — оказалось что нужно отключить их в настройках табов. Хорошо что хоть так работает, плохо что не супер очевидно.
Не хватает предупреждения при попытке закрыть группу вкладок, поэтому страшно не в тот крестик попасть.
Menu Position — Horizontal Menu. Нажимая на Window ожидаешь выпадающий список, а браузер вместо этого сразу в полноэкранный режим переключается. Даже если там всего один пункт в подменю, нельзя так делать.
При правильно подобранной яркости не должны глаза уставать.
Вот, можно поэкспериментировать.
Заодно добавил расчёт контрастности. В рекомендации есть ограничение снизу, однако на тёмных темах ещё и ограничение сверху бы не помешало. Больше 10 мне уже некомфортно.
Это не очень помогает, когда аптайм браузера — от обновления до обновленния.
Хочется устранить этот разрыв, и видеть историю в том порядке, в котором видел страницы я.
Я говорю, что хочу сортировку истории по дате последнего доступа (или закрытия, но подозреваю, что есть ситуации, когда вкладка может потеряться без попадания даты закрытия в историю).
Наиболее логичное решение (возможно, не самое простое, учитывая, что внутри Хромиум) — добавить дополнительные колонки в историю — дата последнего доступа или дата закрытия или обе сразу.