Решил пока написать в это сообщеcтво так как в нем скорее всего наибольший процент "целевой аудитории".
Если коротко,то я написал (ну точнее начал писать, а сейчас оно с одной стороны достаточно юзабельно, а с другой хотелось бы чтобы в дальнейшем оно было таким не только для меня) клиент для diary.ru api.
Второе - причина по которой я им занялся. Т.е. клиент просто пример проекта, относительно простого, но не совсем уж "игрушечного". Ориентированность же на командную строку накладывает определенные ограничения на UI и целевую аудиторию. Собственно из-за них я пишу тут.
Собственно github.com/capgelka/hapidry/blob/master/README.... - краткий мануал, не вижу особого смысла его дублировать сюда.
Но если коротко, то сейчас поддерживаются три вещи с определенным числом опций и способов взаимодействия с ос.
* создание постов
* создание умылов
* Уведомления об умылах/комментах дискуссиях
github.com/capgelka/hapidry/releases/download/v... - свежая linux x64 версия. Внешних зависимостей никаких не должно быть, все статически слинковано, так что должно из коробки заработать на любом дистре.
github.com/capgelka/hapidry/releases/download/v... - последняя windows сборка. Функционала чуть меньше, но в целом тоже юзабельно.
Вообще windows отличается отсутствием поддержки набора текста во внешнем редакторе, т.е. возобновить создание виндовых сборок не проблема. Просто я очень сомневаюсь что windows-юзеров такие вещи интересуют.
x86 linux сборка будет, скорее всего уже сегодня вечером.
Если вдруг кто-то с маком и хочет, то придется компилировать самому, увы(
Чего было бы здорово получить
* Пользователей
* фидбек от пользователей, в том числе потенциальных. Чтобы я мог ориентироваться не только на себя в дальнейших наработках
* Если кто-то желает присоединиться или оставить технические замечания будучи гуру, я только за, но это кажется маловероятным и пишу не ради этого.
Но вообще я особо иллюзий не питаю на счет потенциальной популярности, 2-3 человека, которые найдут применения и возжелают еще функционала это уже отлично.
Пока мне наиболее интересны следующие вещи
* какие опции еще нужны для нотификаций
* есть ли у кого более интеерсные варианты реализации добавления комментов, или таки ничего лучше естественного по id поста не придумать.
* Как лучше реализовать чтение избранного/конкретных дневников и комментов к этому. Пока думаю комменты по айдишника придется, а остальное просто лентой вываливать с кратким содержимым и айдишниками указанными.
Консольный клиент удобен, например, для публикаций записей по расписанию.
Консольный клиент удобен, например, для публикаций записей по расписанию.
Ну я думаю, это проще делать средствами ОС с использованием клиента. Для простого случая 10 строчек на баше, а какой-то сложный сценарий в этом плане даже в голову не идёт.
А так есть еще какие-нибудь идеи, что изменить и/или добавить?
Bad, Если под мак скомпилять, то будет работать под мак (т.к. OS X вроде POSIX, то функционально даже не будет урезан как windows версия). У меня мака нет, как обстоят дела с запустить его в виртуальной машине на обычном PC - хз, но если окажется что особых проблем с этим нет, то пожалуй заведу себе виртуалку c ним. Но в любом случае нет никаких проблем скомпилировать все непосредственно обладателю мака.
ghcformacosx.github.io/
А потом в директории с исходниками stack setup && stack build.
Но вот только я не уверен, что консольный клиент это то о чем может мечтать пользователь мака)
очевидно, что добавить можно всё, что умеет делать браузер.
А из неочевидного - сбор статистики, парсинг постов, активность избранного и т.д, и т.п.
На самом деле, кстати нет. Точнее можно, но тогда придется уже использовать не API а парсить странички.
Например никак не поддерживаются группы, ни в каком виде (ну точнее я не нашел в документации такой информации). То есть нельзя оперировать группами избранного, создавать группы/использовать готовые группы пользователей для ограничения доступа, управлять правами доступа в дневник. И это только то, на что я обратил внимание. Но конечно можно реализовать часть этого функционала храня группы локально, но это все-таки немного не то
Ну и кстати не поддерживается юникод) Точнее, скажем, получить содержимое с японскими иероглифами с дайри можно (хотя сейчас декодер очент кривой и декодирует из \uxxx только кириллицу, но это поправимо), а вот отправить его - никак. cp1251Пока писал это стал думал над тем можно ли это обойти как-нибудь закодировав, и обнаружил кнопочку Unicode в панели браузера. Судя по всему использование "" поможет. Надо будет попробовать. Вот в общем это первое чем я займусь, а то как красноглазые анимешники будут постить японские смайлы.Ну и я неправильно сказал) Интересно что нужно добавить. Т.е. "Вот если бы была такая фича, то я бы был очень рад и стал ей активно пользоваться, потому что это то что мне давно нужно".
Вот сбор статистики всякой идея интересная, хотя надо думать что именно.
В общем пока, получается, не считая рефакторинга приоритеты такие.
1) Постить юникод
2) Опция для комментирование (по id). 2ым пунктом так как её реализовать в таком виде должно быть очень просто.
3) получение списка постов/умылов
4) что-нибудь со статистикой.
Новая сборка будет в воскресенье вечером (ну или в понедельник ночью). Первые два пункта с вероятностью 0.95 будут реализованы, третий пока кажется маловероятным, но может быть частично.
Так что буду писать еженедельные релизы сюда теперь комментами. Кому интересно - будет в курсе, кому не нужно - отпишется.
В новой сборке 0.2.3 реализована поддержка пунктов 1 и 2 Еще кстати обнаружил интересный баг, но он не специфичен для клиента, а для всего дайри так. В общем внутри тем юникод не работает, а все потому что ";" используется как разделитель.
+ наконец поднял виртуалку с 32битной убунтой для 32битных сборок.
github.com/capgelka/hapidry/releases/tag/v0.2.3 скачать новую версию можно тут.
На этой неделе планирую наконец реализовать чтение постов и умылок + появилась идея как добавить интерактивность и сделать клиент юзабельным для относительно нормального человека, но это едва ли на неделе будет.
P.S. Идея про интерактивность пока идея, так как потребует много работы, а непонятно кому это нужно.