 ping
II/IDEC networks :: develop.16 :: Обсуждение вопросов программирования / feed
|
Contacts :: Login |
[>]
Re: Emacs. Редактирование одного текста в нескольких местах
develop.16
Difrex(dynamic,1) — Andrew Lobanov
2019-03-01 07:43:02
> Вспомнил. Я его смотрел, но как-то не вкурил его философию. Выглядит круто, возможности прикольные, но пользоваться им я так и не научился.
Там фишка в том, что есть демон, который реализует сам WM, и клиент к нему. И весь конфиг клиентом делается.
Это позволяет писать конфиг на любом языке.
develop.16
Difrex(dynamic,1) — Andrew Lobanov
2019-03-01 07:43:02
> Вспомнил. Я его смотрел, но как-то не вкурил его философию. Выглядит круто, возможности прикольные, но пользоваться им я так и не научился.
Там фишка в том, что есть демон, который реализует сам WM, и клиент к нему. И весь конфиг клиентом делается.
Это позволяет писать конфиг на любом языке.
[>]
Re: Emacs. Редактирование одного текста в нескольких местах
develop.16
Andrew Lobanov(tavern,1) — Difrex
2019-03-01 08:57:07
>> Вспомнил. Я его смотрел, но как-то не вкурил его философию. Выглядит круто, возможности прикольные, но пользоваться им я так и не научился.
Difrex> Там фишка в том, что есть демон, который реализует сам WM, и клиент к нему. И весь конфиг клиентом делается.
Difrex> Это позволяет писать конфиг на любом языке.
Примерно как в bspwm, видимо. Есть bspwm и есть bspwmc. Конфиг на чём угодно, что умеет в шелл-вызовы. Для управления исключительно bspwmc юзается. Вкупе с sxhkd очень вкусно получается.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
develop.16
Andrew Lobanov(tavern,1) — Difrex
2019-03-01 08:57:07
>> Вспомнил. Я его смотрел, но как-то не вкурил его философию. Выглядит круто, возможности прикольные, но пользоваться им я так и не научился.
Difrex> Там фишка в том, что есть демон, который реализует сам WM, и клиент к нему. И весь конфиг клиентом делается.
Difrex> Это позволяет писать конфиг на любом языке.
Примерно как в bspwm, видимо. Есть bspwm и есть bspwmc. Конфиг на чём угодно, что умеет в шелл-вызовы. Для управления исключительно bspwmc юзается. Вкупе с sxhkd очень вкусно получается.
+++ Caesium/0.4 RC1
+++ Лично я вижу в этом перст судьбы — шли по лесу и встретили программиста.
[>]
Re: CI
develop.16
vit01(mira, 1) — Difrex
2019-03-16 16:32:48
vit01>> Вот я потому дженкинс и решил попробовать - из-за его тяжёлости и фичастости. Хочется оценить в работе все возможные фишки CI и потом сформировать личные предпочтения.
Difrex> Все возможные фишки все-равно не оченишь. Нужно от задачи отталкиваться. Если задача просто собрать проект и выкатить артифакт, то и писать на груви и динамически генерировать джобы через xml rpc тебе вряд ли понадобиться.
Писать на Groovy мне, конечно же, нафиг не сдалось, но вот в перспективе генерировать билды через xmlrpc - почему бы и нет? Всякое может быть
В Дженкинсе я разочаровался. В последнее время, он начал рандомно забивать в лог-файл текстовик с ошибками на несколько гигабайт.
Обновить плагины невозможно, внутренняя обновлялка выдаёт exception-ы.
Да и загружать собранную инфу через SSH дистрибутив тоже нынче отказался. Так что повозился с ним и заменил очередными баш-скриптом.
vit01>> "Может быть, достаточно было ограничиться одним bash-скриптом?"
Difrex> Какие сомнения? Gitlab CI очень фичаст, и его огромный плюс в том, что ты держишь конфигурацию билда прямо в репозитории твоего проекта.
Gitlab CI, может быть, очень фичаст, но для его использования надо пользоваться гитлабом, а на текущем этапе мне это пока нецелесообразно.
Difrex> Еще и всяких гуйней нет, что плюс. Drone CI менее фичаст, но умеет тоже много чего.
Drone CI тянет за собой Docker и, насколько понимаю, запускает его на каждый чих, при каждой сборке. Это оттолкнуло сразу
В идеале, конечно, хотелось бы что-нибудь подобного с синтаксисом вроде Ansible playbook, но чтобы многие вещи для сборки и развёртки были автоматизированы и был удобный гуй на всякий случай.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
develop.16
vit01(mira, 1) — Difrex
2019-03-16 16:32:48
vit01>> Вот я потому дженкинс и решил попробовать - из-за его тяжёлости и фичастости. Хочется оценить в работе все возможные фишки CI и потом сформировать личные предпочтения.
Difrex> Все возможные фишки все-равно не оченишь. Нужно от задачи отталкиваться. Если задача просто собрать проект и выкатить артифакт, то и писать на груви и динамически генерировать джобы через xml rpc тебе вряд ли понадобиться.
Писать на Groovy мне, конечно же, нафиг не сдалось, но вот в перспективе генерировать билды через xmlrpc - почему бы и нет? Всякое может быть
В Дженкинсе я разочаровался. В последнее время, он начал рандомно забивать в лог-файл текстовик с ошибками на несколько гигабайт.
Обновить плагины невозможно, внутренняя обновлялка выдаёт exception-ы.
Да и загружать собранную инфу через SSH дистрибутив тоже нынче отказался. Так что повозился с ним и заменил очередными баш-скриптом.
vit01>> "Может быть, достаточно было ограничиться одним bash-скриптом?"
Difrex> Какие сомнения? Gitlab CI очень фичаст, и его огромный плюс в том, что ты держишь конфигурацию билда прямо в репозитории твоего проекта.
Gitlab CI, может быть, очень фичаст, но для его использования надо пользоваться гитлабом, а на текущем этапе мне это пока нецелесообразно.
Difrex> Еще и всяких гуйней нет, что плюс. Drone CI менее фичаст, но умеет тоже много чего.
Drone CI тянет за собой Docker и, насколько понимаю, запускает его на каждый чих, при каждой сборке. Это оттолкнуло сразу
В идеале, конечно, хотелось бы что-нибудь подобного с синтаксисом вроде Ansible playbook, но чтобы многие вещи для сборки и развёртки были автоматизированы и был удобный гуй на всякий случай.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
[>]
Re: CI
develop.16
Difrex(dynamic,1) — vit01
2019-03-16 17:17:44
>Drone CI тянет за собой Docker и, насколько понимаю, запускает его на каждый чих, при каждой сборке. Это оттолкнуло сразу
Почему оттолкнуло? У тебя получаются изолированные повторяемые билды каждый запуск.
GitlabCI тоже все в докере(dind) собирает.
>В идеале, конечно, хотелось бы что-нибудь подобного с синтаксисом вроде Ansible playbook, но чтобы многие вещи для сборки и развёртки были автоматизированы и был удобный гуй на всякий случай.
Посмотри на CircleCI - там LISP(Clojure) :)
А вообще, если ты хочешь опенсорс собирать, то бери TravisCI и не парься со своими серваками.
develop.16
Difrex(dynamic,1) — vit01
2019-03-16 17:17:44
>Drone CI тянет за собой Docker и, насколько понимаю, запускает его на каждый чих, при каждой сборке. Это оттолкнуло сразу
Почему оттолкнуло? У тебя получаются изолированные повторяемые билды каждый запуск.
GitlabCI тоже все в докере(dind) собирает.
>В идеале, конечно, хотелось бы что-нибудь подобного с синтаксисом вроде Ansible playbook, но чтобы многие вещи для сборки и развёртки были автоматизированы и был удобный гуй на всякий случай.
Посмотри на CircleCI - там LISP(Clojure) :)
А вообще, если ты хочешь опенсорс собирать, то бери TravisCI и не парься со своими серваками.
[>]
Re: CI
develop.16
vit01(mira, 1) — Difrex
2019-04-12 15:21:55
>>Drone CI тянет за собой Docker и, насколько понимаю, запускает его на каждый чих, при каждой сборке. Это оттолкнуло сразу
Difrex> Почему оттолкнуло? У тебя получаются изолированные повторяемые билды каждый запуск.
Дело не в этом. Docker - сам по себе оверхед, жрёт кучу свободного места на диске своими образами. Да и как-то ради простенького сборочного процесса сохранять отдельный контейнер жирновато.
Difrex> Посмотри на CircleCI - там LISP(Clojure) :)
Difrex> А вообще, если ты хочешь опенсорс собирать, то бери TravisCI и не парься со своими серваками.
CircleCI и Travis не подходят по причине того, что это Software as a Service. Да, это удобно, быстро, прикольно, но надо всегда иметь способы быть независимыми от чужого дяди.
В конечном итоге придётся, видимо, осваивать докерные штучки вроде DroneCI и GitlabCI, а пока что я делаю тупо всё на баш-скриптах и не заморачиваюсь.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
develop.16
vit01(mira, 1) — Difrex
2019-04-12 15:21:55
>>Drone CI тянет за собой Docker и, насколько понимаю, запускает его на каждый чих, при каждой сборке. Это оттолкнуло сразу
Difrex> Почему оттолкнуло? У тебя получаются изолированные повторяемые билды каждый запуск.
Дело не в этом. Docker - сам по себе оверхед, жрёт кучу свободного места на диске своими образами. Да и как-то ради простенького сборочного процесса сохранять отдельный контейнер жирновато.
Difrex> Посмотри на CircleCI - там LISP(Clojure) :)
Difrex> А вообще, если ты хочешь опенсорс собирать, то бери TravisCI и не парься со своими серваками.
CircleCI и Travis не подходят по причине того, что это Software as a Service. Да, это удобно, быстро, прикольно, но надо всегда иметь способы быть независимыми от чужого дяди.
В конечном итоге придётся, видимо, осваивать докерные штучки вроде DroneCI и GitlabCI, а пока что я делаю тупо всё на баш-скриптах и не заморачиваюсь.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
[>]
Re: CI
develop.16
Difrex(dynamic,1) — vit01
2019-04-13 09:11:01
> Дело не в этом. Docker - сам по себе оверхед, жрёт кучу свободного места на диске своими образами
Не сохраняй их. Держи только нужные.
> Да и как-то ради простенького сборочного процесса сохранять отдельный контейнер жирновато.
Сохраняй полученный артифакт, а не новый образ.
develop.16
Difrex(dynamic,1) — vit01
2019-04-13 09:11:01
> Дело не в этом. Docker - сам по себе оверхед, жрёт кучу свободного места на диске своими образами
Не сохраняй их. Держи только нужные.
> Да и как-то ради простенького сборочного процесса сохранять отдельный контейнер жирновато.
Сохраняй полученный артифакт, а не новый образ.
[>]
Python и магия генераторов
develop.16
Andrew Lobanov(tavern,1) — All
2019-07-24 07:21:25
Продолжаю учиться писать программы на питоне и возник один странный, может быть, вопрос. Есть строка, в которой хранится в "сыром" виде выхлопом x/c. То есть данные в виде
Я её хочу обработать минимальным количеством кода. Так что решил использовать генератор:
Но при этом мне очень не нравится дважды вызванный .split(":"). Можно как-то произвести сплит единожды для каждой итерации или придётся городить огород для этого?
Эффективность обработки также играет для меня роль, так как впоследствии наработанные подходы я наверняка буду пытаться применять и для больших объёмов данных.
develop.16
Andrew Lobanov(tavern,1) — All
2019-07-24 07:21:25
Продолжаю учиться писать программы на питоне и возник один странный, может быть, вопрос. Есть строка, в которой хранится в "сыром" виде выхлопом x/c. То есть данные в виде
echo.area:messages_count
Я её хочу обработать минимальным количеством кода. Так что решил использовать генератор:
{x.split(":")[0]: x.split(":")[1] for x in x_i.split("\n") if ":" in x}
Но при этом мне очень не нравится дважды вызванный .split(":"). Можно как-то произвести сплит единожды для каждой итерации или придётся городить огород для этого?
Эффективность обработки также играет для меня роль, так как впоследствии наработанные подходы я наверняка буду пытаться применять и для больших объёмов данных.
[>]
Re: Python и магия генераторов
develop.16
Andrew Lobanov(tavern,1) — All
2019-07-24 09:18:41
AL> Продолжаю учиться писать программы на питоне и возник один странный, может быть, вопрос. Есть строка, в которой хранится в "сыром" виде выхлопом x/c. То есть данные в виде
AL> ====
AL> echo.area:messages_count
AL> ====
AL> Я её хочу обработать минимальным количеством кода. Так что решил использовать генератор:
AL> ====
AL> {x.split(":")[0]: x.split(":")[1] for x in x_i.split("\n") if ":" in x}
AL> ====
AL> Но при этом мне очень не нравится дважды вызванный .split(":"). Можно как-то произвести сплит единожды для каждой итерации или придётся городить огород для этого?
Благодаря товарищам из Instead группы в ТГ решил это следующим образом:
Если предложите вариант проще и быстрее, то буду рад.
develop.16
Andrew Lobanov(tavern,1) — All
2019-07-24 09:18:41
AL> Продолжаю учиться писать программы на питоне и возник один странный, может быть, вопрос. Есть строка, в которой хранится в "сыром" виде выхлопом x/c. То есть данные в виде
AL> ====
AL> echo.area:messages_count
AL> ====
AL> Я её хочу обработать минимальным количеством кода. Так что решил использовать генератор:
AL> ====
AL> {x.split(":")[0]: x.split(":")[1] for x in x_i.split("\n") if ":" in x}
AL> ====
AL> Но при этом мне очень не нравится дважды вызванный .split(":"). Можно как-то произвести сплит единожды для каждой итерации или придётся городить огород для этого?
Благодаря товарищам из Instead группы в ТГ решил это следующим образом:
{y[0]: int(y[1]) for y in (x.split(":") for x in counts.split("\n") if ":" in x)}
Если предложите вариант проще и быстрее, то буду рад.
[>]
Re: Python и магия генераторов
develop.16
Difrex(dynamic,1) — Andrew Lobanov
2019-07-24 14:37:26
> Я её хочу обработать минимальным количеством кода
В тему, что меня бесит -- это питоновые однострочники. Оно работает не быстрее, чем если ты запишешь это в несколько строк,
а вот читаемость падает.
develop.16
Difrex(dynamic,1) — Andrew Lobanov
2019-07-24 14:37:26
> Я её хочу обработать минимальным количеством кода
В тему, что меня бесит -- это питоновые однострочники. Оно работает не быстрее, чем если ты запишешь это в несколько строк,
а вот читаемость падает.
[>]
Re: Python и магия генераторов
develop.16
Andrew Lobanov(tavern,1) — Difrex
2019-07-25 05:33:30
>> Я её хочу обработать минимальным количеством кода
Difrex> В тему, что меня бесит -- это питоновые однострочники. Оно работает не быстрее, чем если ты запишешь это в несколько строк,
Difrex> а вот читаемость падает.
А мне наоборот компактность кажется читаемее. По крайней мере в генераторах. К тому же зачастую генератор получается быстрее циклического создания списка или словаря, вроде. Но это вкусовщина, конечно.
develop.16
Andrew Lobanov(tavern,1) — Difrex
2019-07-25 05:33:30
>> Я её хочу обработать минимальным количеством кода
Difrex> В тему, что меня бесит -- это питоновые однострочники. Оно работает не быстрее, чем если ты запишешь это в несколько строк,
Difrex> а вот читаемость падает.
А мне наоборот компактность кажется читаемее. По крайней мере в генераторах. К тому же зачастую генератор получается быстрее циклического создания списка или словаря, вроде. Но это вкусовщина, конечно.
[>]
Re: Python и магия генераторов
develop.16
Andrew Lobanov(tavern,1) — Difrex
2019-07-25 05:33:32
>> Я её хочу обработать минимальным количеством кода
Difrex> В тему, что меня бесит -- это питоновые однострочники. Оно работает не быстрее, чем если ты запишешь это в несколько строк,
Difrex> а вот читаемость падает.
Кстати, в итоге сделал вот так вообще. Даёт небольшой прирост в скорости и по идее легче читается.
Кстати, насколько я понял, регулярки в re ложатся в философию питона как родные и всегда есть возможность получить или список или итератор. Или баловаться со смещением в цикле, что навряд ли будет быстро.
Я правильно думаю, что нет простого способа просто следующее совпадение извлечь?
develop.16
Andrew Lobanov(tavern,1) — Difrex
2019-07-25 05:33:32
>> Я её хочу обработать минимальным количеством кода
Difrex> В тему, что меня бесит -- это питоновые однострочники. Оно работает не быстрее, чем если ты запишешь это в несколько строк,
Difrex> а вот читаемость падает.
Кстати, в итоге сделал вот так вообще. Даёт небольшой прирост в скорости и по идее легче читается.
d = {}
for (key, vaule) in re.findall("(.+):(.+)\n", counts):
d[key] = value
Кстати, насколько я понял, регулярки в re ложатся в философию питона как родные и всегда есть возможность получить или список или итератор. Или баловаться со смещением в цикле, что навряд ли будет быстро.
Я правильно думаю, что нет простого способа просто следующее совпадение извлечь?
[>]
Re: Python и магия генераторов
develop.16
Difrex(dynamic,1) — Andrew Lobanov
2019-07-25 07:12:11
> Я правильно думаю, что нет простого способа просто следующее совпадение извлечь?
Ага, нету.
Скомпиль, кстати, регулярку сначала, будет еще быстрее
develop.16
Difrex(dynamic,1) — Andrew Lobanov
2019-07-25 07:12:11
> Я правильно думаю, что нет простого способа просто следующее совпадение извлечь?
Ага, нету.
Скомпиль, кстати, регулярку сначала, будет еще быстрее
r = re.compile("(.+):(.+)\n")
[>]
Re: Python и магия генераторов
develop.16
Andrew Lobanov(tavern,1) — Difrex
2019-07-25 08:52:33
>> Я правильно думаю, что нет простого способа просто следующее совпадение извлечь?
Difrex> Ага, нету.
Понятно. И даже ожидаемо, так как оно немного противоречит философии питона, насколько я её понимаю =)
Difrex> Скомпиль, кстати, регулярку сначала, будет еще быстрее
Difrex> ====
Difrex> r = re.compile("(.+):(.+)\n")
Difrex> ====
Как раз поигрался вчера с этим немного и собирался в ближайшее время коммитнуть это изменение. Спасибо.
develop.16
Andrew Lobanov(tavern,1) — Difrex
2019-07-25 08:52:33
>> Я правильно думаю, что нет простого способа просто следующее совпадение извлечь?
Difrex> Ага, нету.
Понятно. И даже ожидаемо, так как оно немного противоречит философии питона, насколько я её понимаю =)
Difrex> Скомпиль, кстати, регулярку сначала, будет еще быстрее
Difrex> ====
Difrex> r = re.compile("(.+):(.+)\n")
Difrex> ====
Как раз поигрался вчера с этим немного и собирался в ближайшее время коммитнуть это изменение. Спасибо.
[>]
Шуточные песенки про С (Папа может в СИ)
develop.16
Peter(syscall,1) — All
2019-08-10 21:37:37
Случайно наткнулся на это чудо (Папа может в СИ): https://m.youtube.com/watch?v=cdX8r3ZSzN4
А искал, на самом деле, вот это (Write in C): https://www.youtube.com/watch?v=XHosLhPEN3k
Но вторая -- давно известная шутка. А вот "ПАПА МОЖЕТ СИ" первый раз услышал. :)
develop.16
Peter(syscall,1) — All
2019-08-10 21:37:37
Случайно наткнулся на это чудо (Папа может в СИ): https://m.youtube.com/watch?v=cdX8r3ZSzN4
А искал, на самом деле, вот это (Write in C): https://www.youtube.com/watch?v=XHosLhPEN3k
Но вторая -- давно известная шутка. А вот "ПАПА МОЖЕТ СИ" первый раз услышал. :)
[>]
Re: Шуточные песенки про С (Папа может в СИ)
develop.16
vit01(mira, 1) — Peter
2019-08-11 08:19:27
Peter> Но вторая -- давно известная шутка. А вот "ПАПА МОЖЕТ СИ" первый раз услышал. :)
Это широко известная группа Научно-Технический Рэп. Их самые хитовые песни - это "Делай бэкап", "Тыжпрограммист", "Дедлайн", "Курим мануал"
А вот по их песням про математику (да, такие у них тоже есть) я на первом курсе заучивал теоремы. Очень креативные тексты и "качающая" музыка.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
develop.16
vit01(mira, 1) — Peter
2019-08-11 08:19:27
Peter> Но вторая -- давно известная шутка. А вот "ПАПА МОЖЕТ СИ" первый раз услышал. :)
Это широко известная группа Научно-Технический Рэп. Их самые хитовые песни - это "Делай бэкап", "Тыжпрограммист", "Дедлайн", "Курим мануал"
А вот по их песням про математику (да, такие у них тоже есть) я на первом курсе заучивал теоремы. Очень креативные тексты и "качающая" музыка.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
[>]
android dev
develop.16
jmaks(tavern,12) — All
2019-11-02 10:20:08
vit01, btimofeev
Подскажите товарищи, накидайте годной маны, как быстро без регистрации и смс, собрать простую приложуху под сабжевую систему на смартвоне любом, умеющую одной кнопкой --пересобирать мир--, запускать стрим потока в строенный в приложуху радиво плеер?!
develop.16
jmaks(tavern,12) — All
2019-11-02 10:20:08
vit01, btimofeev
Подскажите товарищи, накидайте годной маны, как быстро без регистрации и смс, собрать простую приложуху под сабжевую систему на смартвоне любом, умеющую одной кнопкой --пересобирать мир--, запускать стрим потока в строенный в приложуху радиво плеер?!
[>]
Re: android dev
develop.16
btimofeev(tavern,13) — jmaks
2019-11-02 13:08:23
Тебе нужно приложение для проигрывания одной интернет-радиостанции?
Можешь посмотреть исходники приложения Transistor https://github.com/y20k/transistor, оно довольно простое.
[>]
Re: android dev
develop.16
jmaks(tavern,12) — btimofeev
2019-11-02 16:06:17
Да, вполне не плохо. Нечто такое и нужно для начала, попробовать собрать и все такое, изучить готовый код, чтобы размотать что-то свое.
Готовое приложение для одной цели.
Ну и вообще, как бы другие советы, на чем/под чем и как лучше, удобнее, современнее собирать apk?!
develop.16
jmaks(tavern,12) — btimofeev
2019-11-02 16:06:17
Да, вполне не плохо. Нечто такое и нужно для начала, попробовать собрать и все такое, изучить готовый код, чтобы размотать что-то свое.
Готовое приложение для одной цели.
Ну и вообще, как бы другие советы, на чем/под чем и как лучше, удобнее, современнее собирать apk?!
[>]
Re: android dev
develop.16
btimofeev(tavern,13) — jmaks
2019-11-02 18:36:57
jmaks> Ну и вообще, как бы другие советы, на чем/под чем и как лучше, удобнее, современнее собирать apk?!
Проще всего поставить Android Studio https://developer.android.com/studio Программы пишутся на Java/Kotlin/C/C++
Ну а дальше можно начать с изучения документации https://developer.android.com/guide/ или startandroid.ru
Ещё в последнее время становится популярным фреймворк Flutter https://flutter.dev/ Он позволяет писать нативные приложения сразу и для Android и для iOS и для веба. Здесь программы уже пишут на языке Dart. Правда и АПК с хелло ворлдом будет иметь размер мегабайт 10.
[>]
Re: android dev
develop.16
vit01(mira, 1) — jmaks
2019-11-03 17:19:39
jmaks> vit01, btimofeev
jmaks> Подскажите товарищи, накидайте годной маны, как быстро без регистрации и смс, собрать простую приложуху под сабжевую систему на смартвоне любом, умеющую одной кнопкой --пересобирать мир--, запускать стрим потока в строенный в приложуху радиво плеер?!
btimofeev уже всё объяснил, достаточно лишь разгрести исходники парочки приложений-плееров на F-Droid
jmaks> Ну и вообще, как бы другие советы, на чем/под чем и как лучше, удобнее, современнее собирать apk?!
От себя добавлю, что нынче Qt очень подтянулись в поддержке андроида. Если уже знаешь Qt и умеешь на нём писать, то начать и поддерживать приложение будет нетрудно.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
develop.16
vit01(mira, 1) — jmaks
2019-11-03 17:19:39
jmaks> vit01, btimofeev
jmaks> Подскажите товарищи, накидайте годной маны, как быстро без регистрации и смс, собрать простую приложуху под сабжевую систему на смартвоне любом, умеющую одной кнопкой --пересобирать мир--, запускать стрим потока в строенный в приложуху радиво плеер?!
btimofeev уже всё объяснил, достаточно лишь разгрести исходники парочки приложений-плееров на F-Droid
jmaks> Ну и вообще, как бы другие советы, на чем/под чем и как лучше, удобнее, современнее собирать apk?!
От себя добавлю, что нынче Qt очень подтянулись в поддержке андроида. Если уже знаешь Qt и умеешь на нём писать, то начать и поддерживать приложение будет нетрудно.
+++ Отправлено через IDEC Mobile
+++ GNU/Linux, Android, physics, MLP:FIM
[>]
Re: Mutt
develop.16
jmaks(tavern,12) — Andrew Lobanov
2019-11-06 15:38:10
Anotheroneuser>> Не найдётся у кого-нибудь muttrc для mail.yandex? Или ссылки на нормальное руководство.
AL> Ну так mutt это только читалка. Unix-way же. Гуглиться надо, например, про связку mutt + fetchmail + procmail + msmtp.
AL> Mutt для чтения и написания писем, fetchmail скачивает почту с сервера, procmail сортирует её, msmtp отправляет почту.
AL> Если не забуду, тр вечером посмотрю у себя. Где-то должны были остаться конфиги для этого добра.
Лучше написать таки своё; и сабж разберёшь, да и свои таки сделаешь настройки.
https://syslogblog.blogspot.com/2008/10/mutt-fetchmail-exim4-smarthost-debian.html
Вот кстати, одна из статеек в этих ваших интернетах; её таки писал сам gl00my aka Peter.
А так да, ничего не поменялось принципиально за много лет.
Вот тут можно поискать настройки и примеры mutt и прочих, линуксформат крутой был журнал. R.I.P.
Press 'F' просто... Эх, грусть...
http://wiki.linuxformat.ru/
У димы можно посмотреть базисные штуки, дефолтные конфиги, довольно много всяких гайдов напилено...
https://www.dmosk.ru/miniinstruktions.php?mini=mutt
На линуксцентре тож, что-то годное помню почерпнул для себя
http://www.linuxcenter.ru/lib/articles/networking/linuxmail.phtml
Так же как и на опеннете
https://www.opennet.ru/docs/RUS/mutt4users/
+++ Caesium/0.4 RC1
develop.16
jmaks(tavern,12) — Andrew Lobanov
2019-11-06 15:38:10
Anotheroneuser>> Не найдётся у кого-нибудь muttrc для mail.yandex? Или ссылки на нормальное руководство.
AL> Ну так mutt это только читалка. Unix-way же. Гуглиться надо, например, про связку mutt + fetchmail + procmail + msmtp.
AL> Mutt для чтения и написания писем, fetchmail скачивает почту с сервера, procmail сортирует её, msmtp отправляет почту.
AL> Если не забуду, тр вечером посмотрю у себя. Где-то должны были остаться конфиги для этого добра.
Лучше написать таки своё; и сабж разберёшь, да и свои таки сделаешь настройки.
https://syslogblog.blogspot.com/2008/10/mutt-fetchmail-exim4-smarthost-debian.html
Вот кстати, одна из статеек в этих ваших интернетах; её таки писал сам gl00my aka Peter.
А так да, ничего не поменялось принципиально за много лет.
Вот тут можно поискать настройки и примеры mutt и прочих, линуксформат крутой был журнал. R.I.P.
Press 'F' просто... Эх, грусть...
http://wiki.linuxformat.ru/
У димы можно посмотреть базисные штуки, дефолтные конфиги, довольно много всяких гайдов напилено...
https://www.dmosk.ru/miniinstruktions.php?mini=mutt
На линуксцентре тож, что-то годное помню почерпнул для себя
http://www.linuxcenter.ru/lib/articles/networking/linuxmail.phtml
Так же как и на опеннете
https://www.opennet.ru/docs/RUS/mutt4users/
+++ Caesium/0.4 RC1
[>]
Признание в любви к Го от старого сишника
develop.16
hugeping(ping,1) — All
2020-09-10 19:45:35
Что бы там не говорили злопыхатели, golang прекрасен! Пока делал ноду, полюбил его ещё больше. Конечно, пока пишу совсем не "идеоматичный" код, но начал постепенно его чувствовать.
Лично для меня это что-то вроде "Си" на стероидах. Что-то между низким уровнем (с его простотой) и современными более абстрактными языками. Идеален для написания бекендов!
А его кросскомпиляция? Наконец-то я избавился от вороха зависимостей, dependency hellов и избежал унылой участи запускать всё в контейнерах. И всё это благодаря go!
Помню, когда читал книжку, чуть не плакал. Везде сквозил дух старого доброго Си, но только переосмысленный.
Короче, Роб Пайк рулит! Спасибо за наше счастливое детство!
[>]
Re: Признание в любви к Го от старого сишника
develop.16
Andrew Lobanov(tavern,1) — hugeping
2020-09-11 04:55:09
hugeping> Что бы там не говорили злопыхатели, golang прекрасен! Пока делал ноду, полюбил его ещё больше. Конечно, пока пишу совсем не "идеоматичный" код, но начал постепенно его чувствовать.
hugeping> Лично для меня это что-то вроде "Си" на стероидах. Что-то между низким уровнем (с его простотой) и современными более абстрактными языками. Идеален для написания бекендов!
hugeping> А его кросскомпиляция? Наконец-то я избавился от вороха зависимостей, dependency hellов и избежал унылой участи запускать всё в контейнерах. И всё это благодаря go!
hugeping> Помню, когда читал книжку, чуть не плакал. Везде сквозил дух старого доброго Си, но только переосмысленный.
hugeping> Короче, Роб Пайк рулит! Спасибо за наше счастливое детство!
Когда пробовал go испытал примерно те же чувства. Пайк и Томпсон всё таки молодцы и понимают в языках :)
develop.16
Andrew Lobanov(tavern,1) — hugeping
2020-09-11 04:55:09
hugeping> Что бы там не говорили злопыхатели, golang прекрасен! Пока делал ноду, полюбил его ещё больше. Конечно, пока пишу совсем не "идеоматичный" код, но начал постепенно его чувствовать.
hugeping> Лично для меня это что-то вроде "Си" на стероидах. Что-то между низким уровнем (с его простотой) и современными более абстрактными языками. Идеален для написания бекендов!
hugeping> А его кросскомпиляция? Наконец-то я избавился от вороха зависимостей, dependency hellов и избежал унылой участи запускать всё в контейнерах. И всё это благодаря go!
hugeping> Помню, когда читал книжку, чуть не плакал. Везде сквозил дух старого доброго Си, но только переосмысленный.
hugeping> Короче, Роб Пайк рулит! Спасибо за наше счастливое детство!
Когда пробовал go испытал примерно те же чувства. Пайк и Томпсон всё таки молодцы и понимают в языках :)
[>]
Re: Признание в любви к Го от старого сишника
develop.16
boscholeg(ping,5) — hugeping
2020-09-11 12:34:46
Вы его так рекламируете. Что хочется прям почитать про этот ваш Го.
Хотя после си, перла, пхп, питона и "богомерзкого" JSа в голове и так полная каша. :(
Жаль мозги прокачать не получается.
[>]
Re: Признание в любви к Го от старого сишника
develop.16
hugeping(ping,1) — boscholeg
2020-09-11 12:46:28
> Вы его так рекламируете. Что хочется прям почитать про этот ваш Го.
Если нравится Си, то понравится и Go. Хотя я был уже подготовлен Питоном и Lua, но всё-равно, думаю, понравится.
[>]
Фантастические консоли и где они обитают
develop.16
johnbrown(ping,9) — All
2020-09-25 18:16:12
Изучаю, время от времени, консоли из этого списка: https://github.com/paladin-t/fantasy
Приглядываюсь, прицениваюсь, так сказать. Тики, Пики, Лики... Хочется низкоуровневой 8-битной экзотики на асме или чтобы вообще без кода. Думал уже ничего не может быть проще Битси. Оказалось, может.
PIX64. Это такой no-code в "пейнте". А может и не в "пейнте". Ну, то есть, берем мышку, создаем 64x64 png, и оно как-то там само все движется...
Осталось только найти для него удобный редактор. А в идеале - конвертер, чтобы из npp прямо в png, типа как xmp (кстати, кроме гимпа, кто-нибудь может работать с этим форматом?)
А вы себе что присмотрели?
[>]
Re: Фантастические консоли и где они обитают
develop.16
btimofeev(ping,6) — johnbrown
2020-09-26 06:36:16
Я когда-то интересовался одной из первых подобных платформ, разработанной еще в 70-х годах - CHIP-8. Там всего два цвета на экране, разрешение 64х32, 16 кнопок клавиатуры, из звуков только "Бииип" и игры пишутся на ассемблере. Но игры конечно простенькие - пинг-понг, арканоиды и подобное. Я учился азам написания эмуляторов на этой системе - вот тут мой эмулятор лежит https://github.com/btimofeev/emuchip
[>]
Re: Фантастические консоли и где они обитают
develop.16
hugeping(ping,1) — johnbrown
2020-09-26 08:49:01
Если мне захочется "живого" железа, я скорее всего выберу спектрум. В детстве я программировал на БК0010-01, а вокруг были спектрумы. Поэтому, интересно. :) Даже читал книгу по железу спека не так давно. Но реально, не уверен что руки дойдут. Много всего. :) Сейчас вот Plan-9 увлёкся.
А в плане виртуальных консолей, PICO8 для меня лучшая. В ней есть баланс ограничений, которые (на практике проверил) идеально для меня подходят. Жаль, что закрытая только. Но хотя бы формат игр открыт и есть открытые плееры...
[>]
Re: Фантастические консоли и где они обитают
develop.16
johnbrown(ping,9) — btimofeev
2020-09-26 12:55:06
> Я когда-то интересовался одной из первых подобных платформ, разработанной еще в 70-х годах - CHIP-8. Там всего два цвета на экране, разрешение 64х32, 16 кнопок клавиатуры, из звуков только "Бииип" и игры пишутся на ассемблере. Но игры конечно простенькие - пинг-понг, арканоиды и подобное. Я учился азам написания эмуляторов на этой системе - вот тут мой эмулятор лежит https://github.com/btimofeev/emuchip
Там, какой-то высокоуровневый ассембер, как я понял, используется, надеюсь будет полегче. Давно хотел приобщиться. Вчера читал руководство по нему, про звуки ничего не нашёл, думал не поддерживает вообще. Ну, здорово, что консоль реально существовала, не фэнтези )
У меня когда-то был Микроша, но получалось запускать на нем только бейсик, да ещё какой-то текстовый редактор. Там и ассемблер был, но для меня тогда это было что-то инопланетное.
[>]
Re: Фантастические консоли и где они обитают
develop.16
btimofeev(tavern,13) — johnbrown
2020-09-26 13:53:33
johnbrown> Там, какой-то высокоуровневый ассембер, как я понял, используется, надеюсь будет полегче. Давно хотел приобщиться. Вчера читал руководство по нему, про звуки ничего не нашёл, думал не поддерживает вообще. Ну, здорово, что консоль реально существовала, не фэнтези )
Она реально не существовала. Chip-8 больше похож на Java или современные виртуальные консоли, это была типа виртуальная машина которая проигрывала игры написанные на этом простеньким ассемблере. А распространялось это на несколько разных компьютеров тех лет.
Ассемблер там простой, я писал небольшую статью с примерами и разбором кода как выводить изображения и обрабатывать события клавиатуры, если интересно можешь почитать https://emunix.org/post/writing-chip-8-emulator-part-3/
[>]
Re: боны поны и прочее
develop.16
Difrex(dynamic,1) — iiii
2023-01-19 22:13:44
Не вижу смысла в новой эхе. Но, на пример, динамик фетчит все из list.txt. Так что новая эха у меня на ноде появится.
ЗЫ: хочу тянуть по 9000 сообщений
develop.16
Difrex(dynamic,1) — iiii
2023-01-19 22:13:44
Не вижу смысла в новой эхе. Но, на пример, динамик фетчит все из list.txt. Так что новая эха у меня на ноде появится.
ЗЫ: хочу тянуть по 9000 сообщений
[>]
Re: боны поны и прочее
develop.16
Andrew Lobanov(tavern,1) — Difrex
2023-01-20 06:41:35
Difrex> Не вижу смысла в новой эхе. Но, на пример, динамик фетчит все из list.txt. Так что новая эха у меня на ноде появится.
Движение ради движения же.
Difrex> ЗЫ: хочу тянуть по 9000 сообщений
Для этого нам нужно начинать пользоваться технологией :)
+++ Caesium/0.4 RC1
develop.16
Andrew Lobanov(tavern,1) — Difrex
2023-01-20 06:41:35
Difrex> Не вижу смысла в новой эхе. Но, на пример, динамик фетчит все из list.txt. Так что новая эха у меня на ноде появится.
Движение ради движения же.
Difrex> ЗЫ: хочу тянуть по 9000 сообщений
Для этого нам нужно начинать пользоваться технологией :)
+++ Caesium/0.4 RC1
[>]
Re: боны поны и прочее
develop.16
ii.51t.ru(dinozavr,2) — Difrex
2023-01-20 14:45:24
нифига не понял, почему это в develop, но утянул себе develop тоже :)
develop.16
ii.51t.ru(dinozavr,2) — Difrex
2023-01-20 14:45:24
нифига не понял, почему это в develop, но утянул себе develop тоже :)
[>]
Кроссплатформенный календарь на текстовых файлах
develop.16
tuple(ping,54) — All
2024-09-27 12:52:27
Долго искал таковое решение, но не нашёл вообще. А именно: хотелось бы иметь файл или кучку файлов в одном календарном просто текстовом формате, которые будут распознаваться и просматриваться соответствующим календарным софтом и на linux, и на android.
А ещё хотелось бы, чтобы можно было не только просматривать через интерфейс приложений, но и редактировать события, а также уведомления, основанные на времени события... Но это так - мечты.
Существует ли такое решение у кого-нибудь?
---
Из найденного самое ближайшее это использование calcurse - https://github.com/avidseeker/awesome-syncthing#icsx5 . Однако это работает только в одну сторону...
develop.16
tuple(ping,54) — All
2024-09-27 12:52:27
Долго искал таковое решение, но не нашёл вообще. А именно: хотелось бы иметь файл или кучку файлов в одном календарном просто текстовом формате, которые будут распознаваться и просматриваться соответствующим календарным софтом и на linux, и на android.
А ещё хотелось бы, чтобы можно было не только просматривать через интерфейс приложений, но и редактировать события, а также уведомления, основанные на времени события... Но это так - мечты.
Существует ли такое решение у кого-нибудь?
---
Из найденного самое ближайшее это использование calcurse - https://github.com/avidseeker/awesome-syncthing#icsx5 . Однако это работает только в одну сторону...
[>]
Re: Кроссплатформенный календарь на текстовых файлах
develop.16
Andrew Lobanov(tavern,1) — tuple
2024-09-27 13:22:07
tuple> Долго искал таковое решение, но не нашёл вообще. А именно: хотелось бы иметь файл или кучку файлов в одном календарном просто текстовом формате, которые будут распознаваться и просматриваться соответствующим календарным софтом и на linux, и на android.
tuple> А ещё хотелось бы, чтобы можно было не только просматривать через интерфейс приложений, но и редактировать события, а также уведомления, основанные на времени события... Но это так - мечты.
Кхм... Я сейчас как сектант скажу, но Emacs и его Org-mode выглядит как то, что тебе нужно. И даже существенно больше.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
develop.16
Andrew Lobanov(tavern,1) — tuple
2024-09-27 13:22:07
tuple> Долго искал таковое решение, но не нашёл вообще. А именно: хотелось бы иметь файл или кучку файлов в одном календарном просто текстовом формате, которые будут распознаваться и просматриваться соответствующим календарным софтом и на linux, и на android.
tuple> А ещё хотелось бы, чтобы можно было не только просматривать через интерфейс приложений, но и редактировать события, а также уведомления, основанные на времени события... Но это так - мечты.
Кхм... Я сейчас как сектант скажу, но Emacs и его Org-mode выглядит как то, что тебе нужно. И даже существенно больше.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
[>]
Избыток абстракций
develop.16
Andrew Lobanov(tavern,1) — All
2024-09-27 13:26:55
Как бороться с сабжем в легаси-коде? Попадаются прямо такие вещи, что я проямо колдобюсь, когда сталкиваюсь.
Последнее из прекрасного, мьютекс со счётчиком локов, который нигде не используется.
Я ещё могу нафантазировать зачем нужен счётчик ReadLock'ов в RWMutex, но вот в самом обычном мьютексе это нафига? Причём реально по всему проекту этот счётчик не используется нигде.
А ведь для этого наверчена отдельная структура, у неё свои методы, реализующие интерфейс мьютекса, но так как нет в стандартной библиотеке интерфейса мьютекса, то наверчен свой интерфейс, но в итоге везде эти мьютексы летят через пустые интерфейсы.
И вот с одной стороны проделана работа (пусть и без результата, но кто его знает, что там в головах было в древности, может была какая-то красивая идея), а с другой стороны это всё бежит по пустым интерфейсом, ломая весь вкус статической типизации.
Извините, накипело. Я эту лабуду разматывал несколько часов только что, чтобы понять, что вообще такое мне в интерфейс падает, где оно описано и нафиг оно нужно.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
develop.16
Andrew Lobanov(tavern,1) — All
2024-09-27 13:26:55
Как бороться с сабжем в легаси-коде? Попадаются прямо такие вещи, что я проямо колдобюсь, когда сталкиваюсь.
Последнее из прекрасного, мьютекс со счётчиком локов, который нигде не используется.
Я ещё могу нафантазировать зачем нужен счётчик ReadLock'ов в RWMutex, но вот в самом обычном мьютексе это нафига? Причём реально по всему проекту этот счётчик не используется нигде.
А ведь для этого наверчена отдельная структура, у неё свои методы, реализующие интерфейс мьютекса, но так как нет в стандартной библиотеке интерфейса мьютекса, то наверчен свой интерфейс, но в итоге везде эти мьютексы летят через пустые интерфейсы.
И вот с одной стороны проделана работа (пусть и без результата, но кто его знает, что там в головах было в древности, может была какая-то красивая идея), а с другой стороны это всё бежит по пустым интерфейсом, ломая весь вкус статической типизации.
Извините, накипело. Я эту лабуду разматывал несколько часов только что, чтобы понять, что вообще такое мне в интерфейс падает, где оно описано и нафиг оно нужно.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
[>]
Re: Кроссплатформенный календарь на текстовых файлах
develop.16
tuple(ping,54) — Andrew Lobanov
2024-09-27 13:32:42
> Кхм... Я сейчас как сектант скажу, но Emacs и его Org-mode выглядит как то, что тебе нужно. И даже существенно больше.
Я из другой секты - vim. Emacs немного трогал, но не хочу в него погружатся, а то придётся пересматривать парадигмы повседневной работы за компом. Хотелось бы некое независимое от выбранного редактора решение.
develop.16
tuple(ping,54) — Andrew Lobanov
2024-09-27 13:32:42
> Кхм... Я сейчас как сектант скажу, но Emacs и его Org-mode выглядит как то, что тебе нужно. И даже существенно больше.
Я из другой секты - vim. Emacs немного трогал, но не хочу в него погружатся, а то придётся пересматривать парадигмы повседневной работы за компом. Хотелось бы некое независимое от выбранного редактора решение.
[>]
Re: Кроссплатформенный календарь на текстовых файлах
develop.16
shaos(shaos, 2) — tuple
2024-09-27 19:18:28
О - а я из третьей секты :)
Точнее из тех нормальных людей, кто вырос на MS-DOS ;)
Я с конца 90х все свои программы пишу в mcedit (mc это клон нортон коммандера для линуха), хотя в 1996-1997 немного посидел в редакторе joe, так как у него комбинации клавиш повторяли борландовские (aka WordStar shortcuts)…
develop.16
shaos(shaos, 2) — tuple
2024-09-27 19:18:28
О - а я из третьей секты :)
Точнее из тех нормальных людей, кто вырос на MS-DOS ;)
Я с конца 90х все свои программы пишу в mcedit (mc это клон нортон коммандера для линуха), хотя в 1996-1997 немного посидел в редакторе joe, так как у него комбинации клавиш повторяли борландовские (aka WordStar shortcuts)…
[>]
Re: Избыток абстракций
develop.16
shaos(shaos, 2) — Andrew Lobanov
2024-09-27 19:25:21
> Как бороться с сабжем в легаси-коде?
Бороться надо на этапе разработки - надо становиться техлидом и пинать разрабов чтобы они не вылезали за рамки техзадания - многие молодые разработчики (особенно российские) норовят на любую тривиальную задачу нагородить «сферического коня в вакууме» - суперуниверсальное решение, которое не только поставленную задачу решает, но и любые другие сходные с ней или которые могут возникнуть на базе текущей задачи в ближайшую сотню лет - в итоге получается овердохера кода который может поддерживать только первоначальный автор, тем самым обеспечивая себе «job security»…
develop.16
shaos(shaos, 2) — Andrew Lobanov
2024-09-27 19:25:21
> Как бороться с сабжем в легаси-коде?
Бороться надо на этапе разработки - надо становиться техлидом и пинать разрабов чтобы они не вылезали за рамки техзадания - многие молодые разработчики (особенно российские) норовят на любую тривиальную задачу нагородить «сферического коня в вакууме» - суперуниверсальное решение, которое не только поставленную задачу решает, но и любые другие сходные с ней или которые могут возникнуть на базе текущей задачи в ближайшую сотню лет - в итоге получается овердохера кода который может поддерживать только первоначальный автор, тем самым обеспечивая себе «job security»…
[>]
Re: Кроссплатформенный календарь на текстовых файлах
develop.16
tuple(ping,54) — shaos
2024-09-27 19:47:22
Родился после 2000-го года, не застал того времени. Году в 19-ом попался мне на глаза Luke Smith вот закрутилось и завертелось у меня с vim'ом.
develop.16
tuple(ping,54) — shaos
2024-09-27 19:47:22
Родился после 2000-го года, не застал того времени. Году в 19-ом попался мне на глаза Luke Smith вот закрутилось и завертелось у меня с vim'ом.
[>]
Re: Кроссплатформенный календарь на текстовых файлах
develop.16
btimofeev(ping,6) — tuple
2024-09-27 21:00:40
tuple> Я из другой секты - vim. Emacs немного трогал, но не хочу в него погружатся
Да ты не переживай, там надо только c org-mode разобраться (почитай доку - это реально очень крутой органайзер https://orgmode.org/ ).
Я тоже когда-то vim использовал (да и сейчас везде где можно стрелки на hjkl), но после знакомства с org-mode больше начал пользоваться емаксом.
P.S. Edited: 2024-09-27 21:00:50
[>]
Re: Кроссплатформенный календарь на текстовых файлах
develop.16
Andrew Lobanov(tavern,1) — tuple
2024-09-28 08:41:03
>> Кхм... Я сейчас как сектант скажу, но Emacs и его Org-mode выглядит как то, что тебе нужно. И даже существенно больше.
tuple> Я из другой секты - vim. Emacs немного трогал, но не хочу в него погружатся, а то придётся пересматривать парадигмы повседневной работы за компом. Хотелось бы некое независимое от выбранного редактора решение.
Это PlainText. Просто есть встроенный софт, который делает всё, что тебе нужно.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
develop.16
Andrew Lobanov(tavern,1) — tuple
2024-09-28 08:41:03
>> Кхм... Я сейчас как сектант скажу, но Emacs и его Org-mode выглядит как то, что тебе нужно. И даже существенно больше.
tuple> Я из другой секты - vim. Emacs немного трогал, но не хочу в него погружатся, а то придётся пересматривать парадигмы повседневной работы за компом. Хотелось бы некое независимое от выбранного редактора решение.
Это PlainText. Просто есть встроенный софт, который делает всё, что тебе нужно.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
[>]
Re: Избыток абстракций
develop.16
Andrew Lobanov(tavern,1) — shaos
2024-09-28 08:41:04
>> Как бороться с сабжем в легаси-коде?
shaos> Бороться надо на этапе разработки
У меня нет машины времени, чтобы вернуться на шесть лет назад.
shaos> надо становиться техлидом и пинать разрабов чтобы они не вылезали за рамки техзадания
Обычно так и пишем. Но в старом коде море говнокода.
shaos> многие молодые разработчики (особенно российские) норовят на любую тривиальную задачу нагородить «сферического коня в вакууме» - суперуниверсальное решение, которое не только поставленную задачу решает, но и любые другие сходные с ней или которые могут возникнуть на базе текущей задачи в ближайшую сотню лет - в итоге получается овердохера кода который может поддерживать только первоначальный автор, тем самым обеспечивая себе «job security»…
Универсальность это хорошо. Только не ценой сложного и запутанного кода. Есть же, в конце концов, паттерны под это.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
develop.16
Andrew Lobanov(tavern,1) — shaos
2024-09-28 08:41:04
>> Как бороться с сабжем в легаси-коде?
shaos> Бороться надо на этапе разработки
У меня нет машины времени, чтобы вернуться на шесть лет назад.
shaos> надо становиться техлидом и пинать разрабов чтобы они не вылезали за рамки техзадания
Обычно так и пишем. Но в старом коде море говнокода.
shaos> многие молодые разработчики (особенно российские) норовят на любую тривиальную задачу нагородить «сферического коня в вакууме» - суперуниверсальное решение, которое не только поставленную задачу решает, но и любые другие сходные с ней или которые могут возникнуть на базе текущей задачи в ближайшую сотню лет - в итоге получается овердохера кода который может поддерживать только первоначальный автор, тем самым обеспечивая себе «job security»…
Универсальность это хорошо. Только не ценой сложного и запутанного кода. Есть же, в конце концов, паттерны под это.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
[>]
Re: Кроссплатформенный календарь на текстовых файлах
develop.16
Andrew Lobanov(tavern,1) — shaos
2024-09-28 08:41:04
shaos> О - а я из третьей секты :)
shaos> Точнее из тех нормальных людей, кто вырос на MS-DOS ;)
Тогда я предпочитал борландовские IDE. Но, как позже оказалось, есть более интересные и совершенные решения.
shaos> Я с конца 90х все свои программы пишу в mcedit (mc это клон нортон коммандера для линуха), хотя в 1996-1997 немного посидел в редакторе joe, так как у него комбинации клавиш повторяли борландовские (aka WordStar shortcuts)…
Mcedit уже даже для конфигов перестал использовать. Быстрее в vim поправить конфиг :)
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
develop.16
Andrew Lobanov(tavern,1) — shaos
2024-09-28 08:41:04
shaos> О - а я из третьей секты :)
shaos> Точнее из тех нормальных людей, кто вырос на MS-DOS ;)
Тогда я предпочитал борландовские IDE. Но, как позже оказалось, есть более интересные и совершенные решения.
shaos> Я с конца 90х все свои программы пишу в mcedit (mc это клон нортон коммандера для линуха), хотя в 1996-1997 немного посидел в редакторе joe, так как у него комбинации клавиш повторяли борландовские (aka WordStar shortcuts)…
Mcedit уже даже для конфигов перестал использовать. Быстрее в vim поправить конфиг :)
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
[>]
Re: Кроссплатформенный календарь на текстовых файлах
develop.16
Andrew Lobanov(tavern,1) — btimofeev
2024-09-28 08:41:04
tuple>> Я из другой секты - vim. Emacs немного трогал, но не хочу в него погружатся
btimofeev> Да ты не переживай, там надо только c org-mode разобраться (почитай доку - это реально очень крутой органайзер https://orgmode.org/ ).
Именно org-mode стал для меня первым шагом в переходе с vim на emacs. Хотя, для мелких вещей и по ssh до сих пор предпочитаю vim.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
develop.16
Andrew Lobanov(tavern,1) — btimofeev
2024-09-28 08:41:04
tuple>> Я из другой секты - vim. Emacs немного трогал, но не хочу в него погружатся
btimofeev> Да ты не переживай, там надо только c org-mode разобраться (почитай доку - это реально очень крутой органайзер https://orgmode.org/ ).
Именно org-mode стал для меня первым шагом в переходе с vim на emacs. Хотя, для мелких вещей и по ssh до сих пор предпочитаю vim.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
[>]
Re: Кроссплатформенный календарь на текстовых файлах
develop.16
tuple(ping,54) — Andrew Lobanov
2024-09-28 09:19:11
Скажем так: у меня "стэк" системы заметок не позволяет перейти на org-mode легко. Веду нечто вроде vimwiki (+одноимённый плагин), стараясь следовать методу Zettelkasten. И это всё дело сидит в markdown, от которого уходить не хотелось бы.
Конкретно сейчас список дел лежит в виде todo.txt (https://github.com/todotxt/todo.txt). А вот хотелось бы найти формат похожий, но для календарных событий.
Есть calendar.txt, однако он не имеет никакой поддержки - никому неизвестен.
Есть утилита remind (https://wiki.archlinux.org/title/Remind), но достаточно устарела, неудобна с русским языком.
develop.16
tuple(ping,54) — Andrew Lobanov
2024-09-28 09:19:11
Скажем так: у меня "стэк" системы заметок не позволяет перейти на org-mode легко. Веду нечто вроде vimwiki (+одноимённый плагин), стараясь следовать методу Zettelkasten. И это всё дело сидит в markdown, от которого уходить не хотелось бы.
Конкретно сейчас список дел лежит в виде todo.txt (https://github.com/todotxt/todo.txt). А вот хотелось бы найти формат похожий, но для календарных событий.
Есть calendar.txt, однако он не имеет никакой поддержки - никому неизвестен.
Есть утилита remind (https://wiki.archlinux.org/title/Remind), но достаточно устарела, неудобна с русским языком.
[>]
Re: Кроссплатформенный календарь на текстовых файлах
develop.16
Andrew Lobanov(tavern,1) — tuple
2024-09-28 09:32:44
tuple> Скажем так: у меня "стэк" системы заметок не позволяет перейти на org-mode легко. Веду нечто вроде vimwiki (+одноимённый плагин), стараясь следовать методу Zettelkasten. И это всё дело сидит в markdown, от которого уходить не хотелось бы.
Ну ой тогда :)
tuple> Конкретно сейчас список дел лежит в виде todo.txt (https://github.com/todotxt/todo.txt). А вот хотелось бы найти формат похожий, но для календарных событий.
Звучит как часок не перле.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
develop.16
Andrew Lobanov(tavern,1) — tuple
2024-09-28 09:32:44
tuple> Скажем так: у меня "стэк" системы заметок не позволяет перейти на org-mode легко. Веду нечто вроде vimwiki (+одноимённый плагин), стараясь следовать методу Zettelkasten. И это всё дело сидит в markdown, от которого уходить не хотелось бы.
Ну ой тогда :)
tuple> Конкретно сейчас список дел лежит в виде todo.txt (https://github.com/todotxt/todo.txt). А вот хотелось бы найти формат похожий, но для календарных событий.
Звучит как часок не перле.
+++ Лично я вижу в этом перст судьбы – шли по лесу и встретили программиста.
[>]
Re: Избыток абстракций
develop.16
shaos(shaos, 2) — Andrew Lobanov
2024-09-29 01:23:28
> У меня нет машины времени, чтобы вернуться на шесть лет назад.
Ну ой тогда :)
Если старый код работает, то не трогайте, а если глючит или тормозит, то аллоцируйте бюджет на "technical debt"...
develop.16
shaos(shaos, 2) — Andrew Lobanov
2024-09-29 01:23:28
> У меня нет машины времени, чтобы вернуться на шесть лет назад.
Ну ой тогда :)
Если старый код работает, то не трогайте, а если глючит или тормозит, то аллоцируйте бюджет на "technical debt"...
[>]
Свой crontab для напоминалок и другого
develop.16
tuple(ping,54) — tuple
2024-10-02 11:17:29
В теории можно сделать упрощённую и переосмысленную версию того, что я описал в начальном сообщении темы. Написать аналог atq.service (который для юниксовой утилиты at), который будет вызывать notify-send с нужными аргументами на основе текстового файлика, синхронизирующегося между устройствами.
Однако возникает проблема с мобильными устройствами. Гуглы закрутили гайки, и отправка уведомлений, и работа в фоне без костылей невозможна. Тот же Telegram FOSS из F-Droid для того, чтобы быть в фоне постоянно, вынужден держать постоянное неубираемое уведомление.
Ещё есть вариант использовать телеграм для уведомлений на мобильных устройствах, можно даже полностью сделать напоминалку исключительно на телеграме - только взаимодействие с ботом без необходимости писать atq. Минусы? Сливать свои данные в телеграм - не лучшая идея, хоть там уже крутиться куча всего. Ну и не unixway'но.
develop.16
tuple(ping,54) — tuple
2024-10-02 11:17:29
В теории можно сделать упрощённую и переосмысленную версию того, что я описал в начальном сообщении темы. Написать аналог atq.service (который для юниксовой утилиты at), который будет вызывать notify-send с нужными аргументами на основе текстового файлика, синхронизирующегося между устройствами.
Однако возникает проблема с мобильными устройствами. Гуглы закрутили гайки, и отправка уведомлений, и работа в фоне без костылей невозможна. Тот же Telegram FOSS из F-Droid для того, чтобы быть в фоне постоянно, вынужден держать постоянное неубираемое уведомление.
Ещё есть вариант использовать телеграм для уведомлений на мобильных устройствах, можно даже полностью сделать напоминалку исключительно на телеграме - только взаимодействие с ботом без необходимости писать atq. Минусы? Сливать свои данные в телеграм - не лучшая идея, хоть там уже крутиться куча всего. Ну и не unixway'но.
[>]
Re: Свой crontab для напоминалок и другого
develop.16
btimofeev(ping,6) — tuple
2024-10-02 11:39:44
tuple> для того, чтобы быть в фоне постоянно, вынужден держать постоянное неубираемое уведомление.
Это же прекрасно. Теперь все подряд приложения не запускают свои бесконечные фоновые сервисы и не сажают этим батарейку.