В своём репозитории сабжа сделал ветку testing.

В этой ветке сделал вывод в красивую таблицу и исправил твой костыль с дублированием кода при выводе информации.
Протестируй и выскажи своё мнение.

./pm.pl -s -n all

Difrex> Есть только проблема с отображением, если uri в ресурсе очень длинный - табличку корежит

Difrex> Я, в принципе, знаю как это поправить.

Там таблица строится очень просто - обычным дополнением пробелов справа.

Если получится починить, то очень хорошо. Сам просто не придумал, как такие случаи обрабатывать. Только если обрезать строку, но это не очень правильно.

Итак, в PM вроде всё устоялось с фичами (если появятся ещё какие-нибудь хотелки, то пусть Денис пишет, поломаю голову).

Надо ещё и больше.

Что можете предложить из того, что не связано с нашей сеткой, но интересно было бы сделать вместе?

// могу и сам чего-нибудь предложить, но сначала подожду

Difrex> Не заинтересует такая штука? https://github.com/Difrex/azot

Забавная вещь. И каковы планы по её улучшению? Делает своё дело, судя по видео, вполне исправно.

Difrex> Жрет ресурсы не в себя. Там постоянно опрашивается положение курсора.

Вроде бы, это единственный рабочий способ для иксов.

Решил проверить, как реализуются действия с углами в аналогах сабжа. Откопал программу brightside (есть в дебиановских репах), посмотрел исходники и обнаружил, что там отслеживание тоже делается с помощью своеобразного таймера, который смотрит положение.

На уровне оконных менеджеров это должно делаться так же.
// тем более, они в любом случае за курсором постоянно следят.

Для производительности можно переписать сабж на Си, но вряд ли будет сильный прирост.
// удивило, кстати, что python2, а не python3

Что думаешь?

Difrex> Например, у меня на федоре иксы через примерно час начинают отлупливать соединения от Azot, типа, слишком часто. Скорее всего надо один раз подключаться и работать в пределах этой сессии, но как это сделать - я не знаю.

Заглянул в исходники X.py из азота. Там такой интересный кусок кода:

def get_cursor_position():
    while 1:
        try:
            data = display.Display().screen().root.query_pointer()._data

            return {'x': data['root_x'], 'y': data['root_y']}

Смущает очень сильно, что ты инициализируешь объект display через display.Display() каждый запуск этой функции. Если учесть, что это происходит постоянно раз в секунду, я не удивляюсь, что иксам это сильно надоедает ;)

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

У меня уже план есть по сабжу:

1. Переписать на python3
2. Убрать костыли и повысить производительность
3. Сделать опцию для ручного указания задержки в конфиге
4. Сделать автоматическую подгрузку конфига, чтобы в самый первый раз не вручную копировать

Если возражений не будет, то примусь за него.

Difrex> ЗЫ: Покажи свои проекты, интересно :)

Если зайдёшь ко мне на гитхаб, то убедишься в том, что смотреть там особо нечего :)
// за исключением сетевых проектов, только это не в счёт

Хотя есть кое-что: https://github.com/vit1-irk/timeleft
Андроид-приложение для товарищей школьников, которое позволяет отслеживать расписание занятий (уроки/пары, перемены). Появилось после экспериментов в ii://linux.14 по NDK: ii://RZdZbVEHDhzU8UcpWJsF
Простое, как валенок, но зато имеет неплохой UI и поддерживает уведомления.

Сделал в сабже вот что:

* Инициализация дисплея для иксов теперь проходит только один раз
* В конфиге можно задавать самому задержку для проверки курсора
* Конфиг в самом начале не надо копировать вручную, программа сделает это сама
(вариант копирования из /usr/share/doc/ тоже работает)
* Теперь азот работает не на втором питоне, а на третьем

По первому пункту скажу, что после исправления сабж у меня исправно проработал около двух часов и никаких болезненных симптомов не показывал. Так что, видимо, проблема решена. Но протестировать всё равно надо.

Серьёзная вещь, надо бы посмотреть.

btimofeev> Но в эмуляторе есть пара ошибок, которые я так и не решил (одна связана с размером окна Qt, вторая с указателями c++).

Если руки дойдут, то и над этим голову поломать можно. Можно поподробнее, что за ошибки?

btimofeev> // а вообще я всегда хотел написать эмулятор Sega Mega Drive, но думаю не дорос еще))

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

btimofeev> 2. ..... Вот передача этого массива между объектами реализована полным копированием, а не передачей указателя. Все мои попытки передать указатель заканчивались segfault'ом. Здесь наверное сказывается мое плохое знание c++, либо неправильная архитектура.

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

Над qt-шной пустой полосой пока думаю.

О, а кода там совсем немного. Уже сейчас успел отправить, можно мержить, собирать и проверять.

Хорошо. А я тут наконец-то выяснил, почему появляется та самая белая полоса внизу окна. Это происходит из-за того, что размеры окна становятся больше, чем размер [холста + меню].

У тебя есть функции set1x(), set2x() и так далее. Внутри них есть такой кусок кода:

setFixedSize (512, 256 + menuBar()->height()); // например, так

Так вот, обнаружил, что перед первой отрисовкой окна (то есть при вызове readSettings() из конструктора) функция height() выдаёт одно значение, а после отрисовки - другое. У меня правильным оказывается второе значение, а первое - на 3 пикселя больше, чем надо.

Варианты: либо продолжить разборки и найти в самом Qt причины этого, либо сделать какой-нибудь костыль.

Починил проблему с полосой, установив EventFilter на событие изменения размера меню.
Заодно сделал получение объекта menuBar единичным, а то как-то не очень хорошо для каждого раза заново метод вызывать.

Хочется ещё и ещё кода понаписать. ;)

Надо бы какой-нибудь покрупнее проект найти.

// Плюсы, кстати, неплохая вещь, особенно, в связке с Qt. Жаль, что раньше никогда почти дел с ними не имел.

vit01> // Плюсы, кстати, неплохая вещь, особенно, в связке с Qt. Жаль, что раньше никогда почти дел с ними не имел.
btimofeev> А мне они уже не нравятся, слишком сложный язык, по-моему.

Смотря с чем сравнивать. Вот если сравнить C++ & Qt с Java на андроиде, то первая связка гораздо приятнее в работе.
А так на питоне проще всего делать. Вот хорошее отличие от питоновского PyQt в том, что не надо заморачиваться с импортами разных фич (т.е. не надо помнить заранее, какая вещь в каком классе находится).

btimofeev> Могу предложить поучаствовать в относительно крупном проекте. Есть очень неплохой консольный музыкальный плеер cmus.

Спасибо за идею. Вот собрал его только что, потом освою и буду исходники курить.

Заняться хакингом сабжа таки получилось. Начал с перемещения неуместного кода для cue в отдельное место (благо оно там уже есть) и с написания отдельного обработчика для "особенных" форматов.
Дальше планирую ещё больше убрать из самого плеера плагин-специфичные куски кода, но с таким количеством хаков и костылей это придётся делать постепенно и небыстро.

Проталкивать в апстрим пока страшновато (несмотря на то, что моя ветка уже собирается и не сегфолтится).

Разработчик мне только сегодня ответил. Пишет, что времени на просмотр кода у него очень мало, но подбадривает и говорит, чтобы я продолжал. Как сделаю большую часть, то пулл-реквест открою.
С кодом cd посложнее будет, потому что там инициализация модуля в самом коде находится. Больше всего вопросов по коду определения типа файла. Но ничего, зато нескучно будет.

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

btimofeev> Можешь еще посмотреть код deadbeef'а, у него внутри плагина доступна функция для добавления нескольких треков.

deadbeef как раз на разные сомнительные штуки имеет функцию плагиноинициализации. Здесь я сделал подобную вещь и тем самым завершил перенос функций добавления плейлиста внутрь плагинов.

Посмотрим, что разработчик ответит: https://github.com/cmus/cmus/pull/460

Корпорация постепенно избавляется от поддержки 32-битных систем в своих инструментах для разработчиков. Так опытным путём я выяснил, что последняя рабочая версия SDK - 24, при этом в ней надо ещё заменить подкаталог build-tools на такой же из 23.0.1.

Последний рабочий вариант NDK - версия 10.

Если попытаться обновить SDK через встроенный конфигуратор, на следующий раз он просто не запустится. И даже не выдаст предупреждения, дескать, "ставится только 64-битная сборка, вы уверены?"

В официальных ChangeLog об изменениях написано вскользь и мелким шрифтом.

Понимаю, конечно, что гуглу просто лень делать сборки, но надо же хоть как-то предупреждать. А то нажал кнопочку "Обновить", и сборочное окружение полностью сломано. Несерьёзно для такой большой корпорации.

И ещё немного упрёков в сторону продуктов сабжа. В системных требованиях для Android Studio указано, что минимальный объём ОЗУ должен быть 2 гига, а рекомендуемый - 8.

На моём ящике с двумя гигами писать для андроида, мягко говоря, проблематично. На нетбуке же (1ГБ) невозможно в принципе (уже пробовал).

Гугл, ты серьёзно? 8 гигов оперативы для мелкого Android-HelloWorld?

Короче, парни, пишите на C++ и Qt. Да, у них тоже есть свои минусы, но зато гораздо ниже системные требования, и оно работает на 32-битных системах. А поддержка Андроида и кроссплатформенности у Qt со временем постоянно улучшается. Кроме этого, можно писать в любимом Vim/Emacs.

AL> Не хочу C++. Правда яву я хочу ещё меньше =)

Пока что, увы, скриптовые языки на мобильных платформах совсем не развиты. Любой подобный эксперимент требует индивидуального подхода и кучи сил/времени.

Я вон тоже мечтаю, чтобы с комфортом можно было писать GUI и на питоне, и на лиспах, и даже на Lua каком-нибудь. В идеале даже прикручивать собственные shared-libraries с любыми биндингами для языков. А ещё чтобы можно было делать пакетирование для андроида полностью из CLI (в том числе на самом девайсе).

Что ж, видимо, прогресс идёт совсем в другую сторону.

vit01>> На моём ящике с двумя гигами писать для андроида, мягко говоря, проблематично. На нетбуке же (1ГБ) невозможно в принципе (уже пробовал).

btimofeev> Я на нетбуке пользовался android studio в течении последних трех лет. Нетбук с 1 гб оперативки и 1.6 Ггц intel atom. Но конечно тормозит оно жестоко.

Пробовал запускать версию 1.4/1.5 буквально в прошлом году. Девайс виснет намертво (примерно на этапе компиляции проекта).

btimofeev> И на python'е плюс kivy.

У kivy есть существенные недостатки, как по мне. Во-первых, недостаёт важных модулей (например, ctypes). Во-вторых, kivy до сих пор не имеет достойного редактора форм (у Qt есть очень удобный Qt Designer), и их придётся писать вручную. Есть, конечно, Kivy Designer, но он настолько сильно тормозит и много падает, что ему даже альфа-статус присваивать рано.

Про поддержку Python3 Андрей уже сказал ранее.

С GoLang дел не имел пока. На текущий момент его осваивать как-то не хочется.

btimofeev> Build tools все поставил 23 версии, так как они 32 битные. Причем виснет даже на сборке хелловорлда. И вот не понятно что теперь делать. Никто с таким не сталкивался?

Примерно сталкивался. У тебя есть Swap-раздел на старом ноуте? Последний раз, когда gradle зависал, его подключение помогло.
Версия SDK тоже 23 или другая? Могу заархивировать собственный и выложить на сервер, если надо.

btimofeev> Если не сложно выложи пожалуйста.

Мой рабочий SDK 24.0.0 с build-tools и platform-tools 23.0.1

http://ii-net.tk/ii/files/sdk-24-tools-23.tar.xz

btimofeev> Напиши, пожалуйста, свои версию gradle плагина, и что ты пишешь в compileSdkVersion и в buildToolsVersion.

    compileSdkVersion 23
    buildToolsVersion "23.0.1"

При этом в dependencies

    compile fileTree(dir: 'libs', include: ['*.jar'])
    testCompile 'junit:junit:4.12'
    compile 'com.android.support:appcompat-v7:24.0.0'
    compile 'com.android.support:support-v4:24.0.0'
    compile 'com.android.support:design:24.0.0'

Всё для gradle вот:

classpath 'com.android.tools.build:gradle:2.1.2'

distributionUrl=https\://services.gradle.org/distributions/gradle-2.10-all.zip

А я вот вчера пробовал завести Docker и обнаружил, что готовые 32-битные образы для него совсем не делают: собирайте, дескать, сами.

Увы, видимо, придётся через пару лет точно так же поступать.

Так, перейдём сюда, чтобы людей не смущать. Как раз эхотаг.

btimofeev> А в чем проблема с SharedPreferences (я с ними никогда не работал)?

1. Чтобы хранить вложенные значения, нужны костыли. Например, люди предлагают всё тот же JSON
2. PreferenceActivity, который работает в связке с этим делом, имеет скудный набор виджетов (например, те же кастомные списки для эхолиста не сделать вообще)
3. Надо реализовывать всё через PreferenceFragment; это довольно небыстро (для кодинга в том числе) и заставляет пользователя дольше кликать, чтобы добраться до нужной настройки

btimofeev> А с json просто работать через библиотеку https://github.com/google/gson

Да, уже слышал про гсон: люди на том же Stackoverflow его постоянно советуют. Но, во-первых, хочется обойтись без внешних библиотек на нижнем уровне (для GUI ещё можно), во-вторых, когда я мельком взглянул на исходники этого чуда, сразу поплохело :)

btimofeev> Сегодня попробовал Instant Run в Android Studio. Это офигительная штука!

Без неё вообще никак. Правда, есть баги: когда изменений всего на пару строк, то IDE может сообщить, что никаких изменений вовсе и не было. Тогда приходится нажимать "rebuild project" и ждать положенные несколько минут.

Хорошо, делай на своё усмотрение.

Кстати, RecyclerView, насколько видно по документации, довольно неплохая штука.
Попробую прикрутить его после того, как кое-какие свои баги наисправляю.

btimofeev> По поводу версий sdk и библиотек: ты не можешь использовать buildtools выше 23.0.1? Support библиотеки 24 версии тоже не работают? Просто чтобы не получилось что я обновлю версии, а у тебя компилироваться не будет.

buildtools точно не получится.

Support-библиотеки (support, design, appcompat) только что поменял на 24 ради эксперимента. IDE сказала, что, дескать, неправильно разные build-tools под разные библиотеки ставить, но проект пересобрался и вроде работает.

На гитхаб оно только что ушло, посмотри build.gradle

// в джаббер тебя добавил, но ты вроде как оффлайн

Текущий прогресс:

1. Сделал дизайн куска сообщения и впихнул его в EchoView-Activity
2. Написал топорный xml для полного просмотрщика сообщений

В планах:

1. Реализовать фрагмент и заодно отдельную активити для просмотрщика сообщений
2. Впихнуть его внутрь ViewPager, чтобы переключать сообщения свайпом
3. Сделать "бесконечную прокрутку" для уже более-менее рабочего RecyclerView
4. Приукрасить всё, чтобы более-менее прилично выглядело (нескучные иконки)
5. Починить баги с DebugActivity, с поиском в БД и c запросом одного отдельного сообщения

Не наступаю ли на где-нибудь на грабли? Можно ли сделать лучше? Вот особенно для пункта 3 сомнения.

В документации пишут, что лучше, дескать, сделать разные активити для разных размеров экранов.

Если будет удача в исправлении багов, с конца следующей недели планирую выкладывать APK для тестирования.

Как раз читал недавно новый холивар на Хабре на эту тему.

Мой главный аргумент, почему табы рулят - это то, что когда хочешь нажать Backspace/Delete для удаления пустого места, то надо сделать это всего 1 раз, а не 4.

В Emacs мне удалось частично побороть эту проблему на пробел-конфигурациях, но только лишь частично.
Просто некоторые major-modes для языков могут насильно сбивать настройки написанных костылей.

В Android-studio (хоть и не на 100%) возню с пробелами компенсирует функция "code beautifier'а".

Среди вас кто-нибудь использует на работе или в собственных проектах технологии или наработки на основе нейронных сетей?

Если да, то какие именно? Что интересного можете припомнить в этой практике?

Что-то неполадки были в жаббере, поэтому можно продолжить дискуссию здесь:

В фетчере я вообще ничего не менял, он работает по-старому, поэтому пока вот так:

1. Какие у тебя настройки были для каждой станции?
2. Увеличивал ли ты лимит /u/e, использовал ли автоконфигурацию?
3. Включал галочку "Качать сообщения дальше"? Не очень я это доработал, так что здесь косяк может быть.

btimofeev> Я исправил тот самый баг с удалением свайпом в черновиках (сделай пулл) и добавил поясняющую иконку на фон при удалении. Можно еще и undo реализовать будет.

Ура! Это очень круто, спасибо! Пересобрал только что и очень доволен.

Undo, наверное, будет лишним.

Подумал тут насчёт продумывания сабжа и зашёл в тупик.

Есть несколько вариантов:

1. Как в ServerListener. Поступление новых сообщений отслеживается через /x/c. Если они имеются, то выводится уведомление: "Новых сообщений: <число>", но при этом ничего на устройство не скачивается. Когда пользователь жмёт на оповещение, то запускается фетчер.

Плюс подхода - избежание "неожиданных ситуаций". Предположим, в эхе ii://pipe.2032 решил нагадить бот/спамер и закинул туда 50000 сообщений. Пользователь смотрит на оповещение и думает: "Ага, что-то тут нечисто!". Потом идёт проверять станцию, а база на телефоне остаётся в чистоте от мусора.

Либо по-другому: любители разного чтива закинули куда-нибудь в ii://lit.14 сразу 50 огроменных рассказов. У пользователя на мобильном интернете остаётся мало трафика, и он осознанно решает не фетчить сообщения до прихода домой, чтобы сэкономить несколько мегабайт.

Минус подхода - использование /x/c. Не все ноды его поддерживают, а фичу хочется для любых станций сразу.

2. Подход "фонового фетча". Фетчер сам запускается и сам фетчит сообщения, а пользователю только говорит о результатах.

Плюсы - универсальность для всех нод и относительная простота реализации.
Минусы - незащищённость базы от спама и от большого трафика.

3. Смесь первого и второго подхода. Делаем проверки не по /x/c, а по индексу, то есть по /u/e.
// Можно даже сделать так, чтобы ноды c /x/c проверялись именно по нему, а ноды без /x/c - по индексу.

Плюсы - поддержка всех нод и защита от спама
Минусы - глюкавость при изменении настроек станций (особенно с расширенным /u/e); постоянный жор трафика независимо от наличия новых сообщений; надо где-то хранить и запоминать индекс вне базы; будет сложнее реализовать этот хитрый алгоритм.

Итак, за что проголосует народ? Может быть, есть, что предложить получше?

Дали мне одно задание - используя API одного сервиса для получения исходных данных, автоматически заполнять бланки для Почты России, чтобы быстро отправлять их на печать. Грубо говоря, написать импровизированного бота, который будет с этим разбираться.

Услышав "PDF", я порадовался и подумал, что "для него уж точно кучу всего написали, проще некуда, найду что-нибудь". Но не тут-то было!

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

Посмотрел в сети, и выяснилось, что проблема библиотеки - в зависимости от libpoppler. Баг в poppler'е затрагивает многие другие приложения, например, Evince. И проблему в последнем до сих пор можно увидеть без особых усилий.

https://bugs.launchpad.net/ubuntu/+source/evince/+bug/1288182
Представьте себе, баг по этой ссылке висит с 2008 года, но так и не исправлен!

----------

Идём по Гитхабу дальше. Все остальные репозитории с нужным мне делом представлены обёртками для программного пакета pdftk.

pdftk имеет множество фич. Можно даже сказать, что это самая популярная вещь для автоматической обработки. Он может "инспектировать" PDF-файлы, декомпилировать их, изменять внутренности и так далее. Работает на основе файлов FDF и XFDF (XML-версия формата). Туда записываются данные для заполнения в декларативном виде, затем скармливаются pdftk, и тот выдаёт заполненный результат.

Но здесь я опять потерпел неудачу. Кириллица снова отказывается отображаться. В багтрекере уже появлялись люди с похожими проблемами, но их мягко посылали. Были люди, которые предлагали обходные пути вроде дополнительных параметров, но здесь они не помогли.

В чём же проблема с ним?

Оказывается, pdftk полностью перестраивает шрифты в выходном документе, полурандомным образом удаляя некоторые из них. Были товарищи, которые советовали подключать позднее свои шрифты через костыли к полям форм, но этот способ слишком ненадёжный и неочевидный. Баг до сих пор толком не исправлен, хотя поддержка юникода, говорят, улучшилась в pdftk с 2 версии (которую я и использовал). Пользователям из России говорят, что эта самая поддержка в pdftk сделана с существенными ограничениями.

-----------

Где же, наконец, простое и рабочее решение для автозаполнения PDF-форм?

Вот оно: https://sourceforge.net/projects/pdfformfiller2/?source=directory
Использует библиотеку iTextPdf 5 версии, написано на Java.

Установка после распаковки zip-а:

1. Требуется OpenJDK 7 или 8
2. Надо скачать iTextPdf отсюда: https://github.com/itext/itextpdf/releases/tag/5.5.10
3. Затем распаковать jar-файлы и положить их в lib/ к pdfformfiller-у
4. Компилируем обёртку
javac -d . -cp lib/itextpdf-5.5.10.jar PdfFormFiller.java

5. Делаем скрипт для запуска утилиты
java -classpath .:lib/itextpdf-5.5.10.jar PdfFormFiller.PdfFormFiller $1 $2 $3 etc

Всё, готово к использованию. Программа принимает в качестве ввода файл с названиями полей ввода и внешний шрифт (в формате ttf), которым надо их заполнять. Может брать данные в том числе из stdin.

Кстати, насчёт остального. Для выяснения, какие шрифты есть в документе, пригодится cli-утилита pdffonts из состава poppler.
Чтобы узнать id полей ввода в документе, можно использовать pdftk file.pdf dump_data_fields, либо сам pdfformfiller, в котором это предусмотрели (см. справка).

AL> Вот меня как раз может ожидать работа с pdf, но из питона. И там может оказаться тоже весьма весело.

Своего бота я как раз на питоне писал, а тулзу запускал через subprocess.Popen, и никаких проблем.
Если нужна работа в read-only (например, любой парсинг или анализ), то тут граблей быть не должно, библиотек куча рабочих как для питона, так и для других языков.

btimofeev> Подскажи, а у тебя телефон без play сервисов?

Да. ОС 7.1.1
Уже давно приспособился жить совсем без гугла.

btimofeev> Если так, то не мог бы ты посмотреть работает ли вот эта версия моего приложения

Нормально установилось и запустилось. Ну а тестировать мне не на чем.

btimofeev> Какие-то эти альтернативные сторы муторные.

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

Прикупил себе китайскую Arduino Uno на али за 190 рублей.
Драйвера подошли стандартные из IDE, правда, приходится перед началом работы делать chmod 777 /dev/ttyUSB0, иначе ничего не прошьётся.
Сама IDE, кстати, не хотела сначала ничего компилировать, ругаясь на отсутствие libtinfo.so.5, но симлинком на libncurses проблема разрешилась.

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

Порылся в закромах, нашёл раздолбанную игрушечную рацию и вытащил оттуда динамик.

Подключил к ардуине, нашёл примеры использования в сети и, о чудо, оно работает!

В общем, попробовал сделать кавер на кусок симфонии Виктора Аргонова (сюда постил уже когда-то). Автор молодец, что полные midi в открытый доступ выкладывает, экспериментировать удобно.

https://ii-net.tk/ii/ii-point.php?q=/x/file/constructing-sensations-arduino.ogg

И исходник на Гитхабе: https://github.com/vit1-irk/constructing-sensations-arduino

Оригинал для сравнения (3 часть, если что) доступен для скачивания здесь: http://argonov.ru/crossing.html

Сомневаюсь, что сабж есть перспективно, но зато хоть как-то современно :)

Когда у меня появилась ардуинка, я хотел приспособить её для какого-нибудь действительно полезного дела. В домашних условиях такая задача всё-таки нашлась :)

Вот представь себе: ты сидишь за столом и слушаешь громкую музыку в наушниках. Может быть, делаешь какие-то другие дела попутно по работе или учёбе. А тут подходит к тебе кто-то из домашних и хочет что-то сказать. Во-первых, этот внешний раздражитель сначала надо заметить (ты ведь под кайфом от громкой музыки, да?). Во-вторых, надо переключиться на плеер и остановить воспроизведение.

Цель: сделать установку на ардуине, которая будет ставить плеер на паузу, когда подходят к твоему "рабочему месту".

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

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

#define pirPin 2  // наш датчик
#define ledPin 13 // светодиод

int wasMotion = false;

void setup() {
  Serial.begin(9600);
  pinMode(pirPin, INPUT);
  pinMode(ledPin, OUTPUT);

  delay(2000); // не активируем цикл сразу, а чуть-чуть подождём
}

void loop() {
  int pirVal = digitalRead(pirPin);

  //Если обнаружили движение
  if (pirVal == HIGH)
  {
    if (wasMotion == false) {
      digitalWrite(ledPin, HIGH);
      Serial.print("Motion detected\n");
      wasMotion = true;
    }
    delay(500); // пауза для прогорания светодиода и для следующей проверки
  } else if (wasMotion == true) {
    wasMotion = false;
    digitalWrite(ledPin, LOW);
  }
}

После заливки скетча надо добавить вашего пользователя в группу uucp, которая позволит считывать данные из виртуального USB-COM порта ардуины без root-прав.

# usermod -a -G uucp youruser

Далее надо было написать программу, которая будет отслеживать сигнал, поступающий с девайса, и подавать сигнал плееру. Питон ради такой мелочи расчехлять не хотелось (будет память жрать), поэтому выбрал C.

#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <signal.h>
#include <stdlib.h>

int fd;
int should_exit = 0;

static void signal_handler(int sig) {
	// Обрабатываем нажатие Ctrl-C, чтобы корректно выходить

	switch (sig) {
		case SIGINT:
			close(fd);
			printf("Exiting\n");
			should_exit = 1;
			break;
		default:
			break;
	}
}

void stop_player() {
	// Главная вещь, ради которой всё затевалось
	// Для плеера Audacious, которым пользуюсь

	system("if [ \"`audtool playback-status`\" = \"playing\" ]; then audtool playback-pause; fi");
}

void main(int argc, char** argv) {
	char buf[15];
	int r;

	signal(SIGINT, signal_handler);

	// Открываем виртуальный USB COM-port девайса
	fd = open("/dev/ttyUSB0", O_RDONLY | O_NOCTTY | O_NDELAY);
	if (fd == -1) {
		perror("open_port: Unable to open /dev/ttyUSB0 - ");
		should_exit = 1;
	} else {
		fcntl(fd, F_SETFL, FNDELAY);
	}

	while(!should_exit) {
		r = read(fd, buf, 20);
		if (r > 0 && strncmp(buf, "Motion detected", 15) == 0) {
			puts("Works!");
			stop_player();
		}
		sleep(1);
	}
}

Всё, можно добавлять в автозагрузку и пользоваться!
И да, как это выглядит на фоточках:

https://ii-net.tk/ii/files/arduino-pir1.jpg
https://ii-net.tk/ii/files/arduino-pir2.jpg

btimofeev> Для андроид обнаружил программку Orgzly

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

У самого для тудушек стоит приложение OpenTasks (уже упоминал его в ii://linux.14). Его плюс в том, что с OwnCloud/NextCloud обменивается и интерфейс с точки зрения кнопкотыкания удобен.

Другое дело, что следовать расписаниям и всяким спискам в целом - это неудобно и часто бессмысленно, потому что планы постоянно перекраиваются, а хотелки меняются. В итоге в конце дня смотришь и понимаешь, что события в реальности произошли совсем в другое время (не так, как предполагалось изначально). Или не произошли (отложились на завтра). Поэтому поигрался с календарями и TODO-шниками, да забросил.
Но это ИМХО.

На Хабре недавно промелькнула статья про технику помидора и Emacs.
https://habrahabr.ru/post/323576/

Ссылка на гитхаб со скриптом: https://github.com/TatriX/pomidor

Симпатичная штука для столь избитой методики повышения производительности :)

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

Порекомендую клиент MGit или его предшественника (по форку) SGit. И коммитить, и пушить, и всё остальное необходимое умеет.
https://f-droid.org/repository/browse/?fdfilter=MGit&fdid=com.manichord.mgit

Кстати, а чем тебя Termux'овский гит не устроил? Это ведь тоже вполне рабочий вариант (даже более идеологически правильный). Пробовал и остался доволен.

Интересно, интересно.
Целый набор "современного" девелопера. Куча джаваскрипта, новомодные angular и react, микросервисы (какой ужас, столько страшилок про них!), а также незаменимый Докер. Зачем туда закинули agile и tdd, вообще без понятия.

Хотя кто знает. Может быть, через год я сам буду клепать что-нибудь на React (если он к тому времени не выйдет из моды).

Из подборок книг больше всего нравится так распиаренный Free Programming Books. Там прямо всё по полочкам разложено в одном файле.

https://github.com/vhf/free-programming-books/blob/master/free-programming-books-ru.md