Приветствую, товарищи. Думаю, все уже давно видят, что в нашей сетке сейчас длительное затишье и скука (за исключением роботов). Но желание сообщать какую-то разную инфу и общаться никуда не подевалось, по крайней мере, у меня

Так вот, в последние пару месяцев я занят работой в Институте Солнечно-Земной физики, связанной с обработкой данных по вспышкам. Кроме этого, в том же институте прохожу практикум по установкам, исследующим земную ионосферу.

За этот период приходилось тратить достаточно много времени, чтобы доносить до своих знакомых инфу об этих "приключениях", и захотелось завести что-то вроде блога, чтобы люди всё читали из одного места. Плюс стало жалко, что люди из IDEC пропускают такой пласт контента.

По тематике планируются посты по типу "за жизнь", где будут заметки про настроение, а также посты про красноглазие, Python и анализ данных.

Планируется немало картинок, например, диска Солнца, магнитограмм, ионограмм и куча графиков. И насчёт этого требуется совет многоуважаемого All

1. В каком формате лучше публиковать картинки? Имеет ли смысл просто вставлять ссылки на них или лучше загружать в файлэху?

2. Имеет смысл постить всё в ii://pipe.2032 или стоит закидывать в отдельную эху?

3. Как организовать автоматический кросспостинг между idec и веб-интерфейсом (например, через RSS или отдельного бота) и стоит ли заниматься этим вообще? (есть вариант просто делать 2 немного разных поста и там, и там)

Пробовал смотреть разные простенькие веб-движки для ведения статических блогов. Особо понравился питоновский Nikola из-за его поддержки постов как в формате Markdown, так и в формате Jupyter Notebook (большинство своих расчётов делаю именно там).

Правда, встроенные картинки и графики в Jupiter Notebook при конвертации в HTML -> plaintext через nbconvert вставляются напрямую в виде data:base64

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

vit01> 1. В каком формате лучше публиковать картинки? Имеет ли смысл просто вставлять ссылки на них или лучше загружать в файлэху?

Лучше загружать в фэху и добавлять в текст ссылки на эти файлы :)

vit01> 2. Имеет смысл постить всё в ii://pipe.2032 или стоит закидывать в отдельную эху?

ИМХО, плодить эхи смысла нет. Лучше писать всё прямо сюда.

vit01> 3. Как организовать автоматический кросспостинг между idec и веб-интерфейсом (например, через RSS или отдельного бота) и стоит ли заниматься этим вообще? (есть вариант просто делать 2 немного разных поста и там, и там)

С точки зрения конечного результата, два поста и там и там будут выглядеть аккуратней, чем автоматический кросс-постинг.

vit01>> 3. Как организовать автоматический кросспостинг между idec и веб-интерфейсом (например, через RSS или отдельного бота) и стоит ли заниматься этим вообще? (есть вариант просто делать 2 немного разных поста и там, и там)

AL> С точки зрения конечного результата, два поста и там и там будут выглядеть аккуратней, чем автоматический кросс-постинг.

Думаю, что здесь лучше именно так и поступить

А насчёт остальных пунктов всё-таки подождём мнения ещё кого-нибудь

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

> 1. В каком формате лучше публиковать картинки? Имеет ли смысл просто вставлять ссылки на них или лучше загружать в файлэху?
Я за ссылки. Поддержка фэх, как я понимаю, сейчас включена только у тебя и Андрея.

> 2. Имеет смысл постить всё в ii://pipe.2032 или стоит закидывать в отдельную эху?
Можно прямо в ii://pipe.2032, но и собственная эха тоже нормально. Только анонс её сюда скинуть было бы неплохо.

> 3. Как организовать автоматический кросспостинг между idec и веб-интерфейсом (например, через RSS или отдельного бота) и стоит ли заниматься этим вообще? (есть вариант просто делать 2 немного разных поста и там, и там)
Лучше два отдельных поста, наверное. Хотя, я свой блог транслирую сюда автоматом через RSS бота.

>> 1. В каком формате лучше публиковать картинки? Имеет ли смысл просто вставлять ссылки на них или лучше загружать в файлэху?
Difrex> Я за ссылки. Поддержка фэх, как я понимаю, сейчас включена только у тебя и Андрея.

Я бы всё таки сделал фэху и кидал ссылку на файл из неё через фрек :)

>>> 1. В каком формате лучше публиковать картинки? Имеет ли смысл просто вставлять ссылки на них или лучше загружать в файлэху?

Difrex>> Я за ссылки. Поддержка фэх, как я понимаю, сейчас включена только у тебя и Андрея.

AL> Я бы всё таки сделал фэху и кидал ссылку на файл из неё через фрек :)

Сделал ссылками на файлы в файлэхе через API. И кому надо, тот подпишется на фэху alicorn.blog

Думаю, по виду ссылок в посте это уже было очевидно.

Ещё составил себе простенький питон-скрипт, который быстро репарсит markdown-исходник статьи и переводит разметку в пригодную для публикации в IDEC. Также ссылки на картинки он регулярками подменяет на соответствующие ссылки из файлэхи, если таковые имеются.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

Немного не по теме. Можно тебя попросить делать строки не такими длинными в посте?
Ограничиться, например, в символов 100. Иначе приходиться включать *visual-line-mode* :)

+++ At work. idec.el/0.1

Difrex> Можно тебя попросить делать строки не такими длинными в посте?
Difrex> Ограничиться, например, в символов 100. Иначе приходиться включать *visual-line-mode* :)

Можно. Правда, все наши остальные клиенты (и редакторы в них) умеют отображать текст с переносами слов.

Из-за этого я специально делал строки длинными, чтобы сэкономить читателю место по вертикали и по горизонтали :)

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

AL>> Я бы всё таки сделал фэху и кидал ссылку на файл из неё через фрек :)
vit01> Сделал ссылками на файлы в файлэхе через API. И кому надо, тот подпишется на фэху alicorn.blog
vit01> Думаю, по виду ссылок в посте это уже было очевидно.
vit01> Ещё составил себе простенький питон-скрипт, который быстро репарсит markdown-исходник статьи и переводит разметку в пригодную для публикации в IDEC. Также ссылки на картинки он регулярками подменяет на соответствующие ссылки из файлэхи, если таковые имеются.

Спасибо.

Всё таки питон в таких ситуациях незаменим. Можно было бы и на баше, но баш сложнее в использовании. Я вон давеча костыль на работе написал для анализа тикетов в редмайне под нужды отдела. Получилось кратко и удобно :)

Difrex> Немного не по теме. Можно тебя попросить делать строки не такими длинными в посте?
Difrex> Ограничиться, например, в символов 100. Иначе приходиться включать *visual-line-mode* :)

Лишние символы переноса строки внутри абзаца есть моветон и кю :)

> Лишние символы переноса строки внутри абзаца есть моветон и кю :)
Где про это можно почитать?

>> Лишние символы переноса строки внутри абзаца есть моветон и кю :)
Difrex> Где про это можно почитать?

Зачем про это читать? На узких окнах сработает автоперенос в дополнение к расставленным автором переносам и будет рваная хрень вместо абзаца. На широких окнах будет узкая колонка текста. В общем, за пределами текстового видеорежима 80х25 или 80х50 оно выглядит неудобно.

Добавь просто в хук на читалку включение автопереноса и всего делов :)

> В общем, за пределами текстового видеорежима 80х25 или 80х50 оно выглядит неудобно.
Но ты же код не пишешь в 200 символов на строку.

> На широких окнах будет узкая колонка текста.
Если зайти, например, на idec.spline-online.tk, то там мы увидем ограничение ширины для удобства чтения постов, как раз узкая колонка текста :).
Проблема в том, что вот этот вот подход с не расстановкой переносов работает для печати или для известной ширины.
Когда у тебя нет ограничения по ширине оно выглядит не особо удобным. Цезий на fullhd https://images.lessmore.pw/media/images/2019-12-05_314-18-33.png.
Неудобно читать такие длинные строки.

> Добавь просто в хук на читалку включение автопереноса и всего делов :)
Добавил.

Difrex> Когда у тебя нет ограничения по ширине оно выглядит не особо удобным. Цезий на fullhd https://images.lessmore.pw/media/images/2019-12-05_314-18-33.png.
Difrex> Неудобно читать такие длинные строки.

Когда у нас есть окно клиента (того же Цезия) или окно в браузере, то мы можем заресайзить его под нужную нам ширину, и текст начнёт выглядеть нормально.

Проблема ручных переносов в том, что текст рвётся в строго определённых местах, и с помощью ресайза окна клиента становится невозможно это починить. В результате текст выглядит хорошо только на каком-то определённом разрешении экрана.

>> Добавь просто в хук на читалку включение автопереноса и всего делов :)
Difrex> Добавил.

То есть проблема решена, и уже можно не заморачиваться? :)

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

>> В общем, за пределами текстового видеорежима 80х25 или 80х50 оно выглядит неудобно.
Difrex> Но ты же код не пишешь в 200 символов на строку.

Код имеет совсем другие критерии в сравнении с обычным текстом. В стихах тоже есть принудительные переносы внутри строфы, но это не значит, что и в обычном тексте их нужно делать.

>> На широких окнах будет узкая колонка текста.
Difrex> Если зайти, например, на idec.spline-online.tk, то там мы увидем ограничение ширины для удобства чтения постов, как раз узкая колонка текста :).
Difrex> Проблема в том, что вот этот вот подход с не расстановкой переносов работает для печати или для известной ширины.

Всё так.

Difrex> Когда у тебя нет ограничения по ширине оно выглядит не особо удобным. Цезий на fullhd https://images.lessmore.pw/media/images/2019-12-05_314-18-33.png.
Difrex> Неудобно читать такие длинные строки.

Это недостаток цезия, КМК, а не текста. В новом цезии, который я тут в свободное время пописываю, я собираюсь предусмотреть возможность изменения ширины текста, а не шпарить его всегда на всю ширину терминала.

>> Добавь просто в хук на читалку включение автопереноса и всего делов :)
Difrex> Добавил.

В общем, моя позиция в этом вопросе такова: представлением текста должна заниматься программа, которая этот текст отображает, а не автор текста или программа, с помощью которого автор этот текст пишет. Принудительные переносы так же, как и их отсутствие, могут плохо выглядеть, если заранее неизвестна ширина области отображения текста.

Конечно, каждый волен писать текст так, как он хочет. Стандартизировать это не имеет смысла. Просто в случае отсутствия принудительных переносов строки проблему неудобоваримого отображения можно решить на клиентской стороне, а в случае их присутствия проблема заметно усложняется и становится нерешаемая без анализатора, который бы эти лишние переносы удалял перед рендером.

AL> В общем, моя позиция в этом вопросе такова: представлением текста должна заниматься программа, которая этот текст отображает, а не автор текста или программа, с помощью которого автор этот текст пишет. Принудительные переносы так же, как и их отсутствие, могут плохо выглядеть, если заранее неизвестна ширина области отображения текста.

Вот же совпадение, в Фидо сейчас прочитал обсуждение этой же самой темы =))

+++ Caesium/0.4 RC1

vit01>> Ещё составил себе простенький питон-скрипт, который быстро репарсит markdown-исходник статьи и переводит разметку в пригодную для публикации в IDEC. Также ссылки на картинки он регулярками подменяет на соответствующие ссылки из файлэхи, если таковые имеются.

AL> Всё таки питон в таких ситуациях незаменим. Можно было бы и на баше, но баш сложнее в использовании. Я вон давеча костыль на работе написал для анализа тикетов в редмайне под нужды отдела. Получилось кратко и удобно :)

Потом уже пришлось написать скрипт-костыль, который загружает нужные файлы в файлэху и даёт способы быстро описание ввести. Ранее приходилось всё грузить с мобилы.

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM

AL>> В общем, моя позиция в этом вопросе такова: представлением текста должна заниматься программа, которая этот текст отображает, а не автор текста или программа, с помощью которого автор этот текст пишет. Принудительные переносы так же, как и их отсутствие, могут плохо выглядеть, если заранее неизвестна ширина области отображения текста.
around> Вот же совпадение, в Фидо сейчас прочитал обсуждение этой же самой темы =))

Тема оформления текста никогда не устареет :)

vit01>>> Ещё составил себе простенький питон-скрипт, который быстро репарсит markdown-исходник статьи и переводит разметку в пригодную для публикации в IDEC. Также ссылки на картинки он регулярками подменяет на соответствующие ссылки из файлэхи, если таковые имеются.
AL>> Всё таки питон в таких ситуациях незаменим. Можно было бы и на баше, но баш сложнее в использовании. Я вон давеча костыль на работе написал для анализа тикетов в редмайне под нужды отдела. Получилось кратко и удобно :)
vit01> Потом уже пришлось написать скрипт-костыль, который загружает нужные файлы в файлэху и даёт способы быстро описание ввести. Ранее приходилось всё грузить с мобилы.

Я разве свой скрипт для отправки файлов в фэхи не публииковал? Или у тебя более автоматизировано?

vit01>> Потом уже пришлось написать скрипт-костыль, который загружает нужные файлы в файлэху и даёт способы быстро описание ввести. Ранее приходилось всё грузить с мобилы.

AL> Я разве свой скрипт для отправки файлов в фэхи не публииковал? Или у тебя более автоматизировано?

Глянул на твой гитхабчик и вижу, что ты выложил более-менее полноценную утилиту. У меня же всего лишь 10-строчник с requests.post, который делал чисто для блога и прикрутил к парочке репарсеров, поэтому выкладывать там нечего.

libra> Кстати, по поводу скриптов. Есть какие у кого решения? где взять пощупать??? поделитесь?? идеи???? для многофайловой обработки каталогов с файлом и генерации файл-индексов= с возможностью ввода description либо без оного, эти desc можно прописать и позже

Description у нас обязательный как в стандарте, так и по задумке. Ибо нефиг засорять файлэхи котами в мешке

libra> К примеру хочется мне сохранить/создать на ноде файлэху и в неё положить разом 50 файлов? Что посоветуете^?

https://github.com/spline1986/idec-utils/blob/master/fecho_send.py

И там же скрипты другие в репе

// Кстати, to AL, перенеси эти скрипты в официальную репу https://github.com/idec-net/idec-utils , чтобы потом не искать их хрен знает где. Мы же специально создали организацию на гитхабе, чтобы весь нужный софт был в одном месте

У меня есть репозиторий https://github.com/idec-net/ii-db-utils

Там ничего для фэх нет, зато есть другие скрипты интересные

+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM