alari / everfeeds Goto Github PK

Для каждого доступатора, который может публиковать, нужно научиться это делать, для начала -- простой текст с заголовком, плюс текущие настройки фильтра ленты -- указание тегов и одной категории.
Начнём с твиттера.
По сути, апи уже есть -- Accessor.push(IEntry entry).

http://vkontakte.ru/topic-1_24428376

вконтакт делает OAuth и даёт доступ к апи.
нужно быть к этому готовыми. это ключ к российскому рынку :)

Вообще оно работало раньше, но почему-то перестало.

Задача: логи приложения начиная с уровня debug должны записываться в собственный файл аппликейшна.

После выбора тегов и категорий в правой колонке, должно появляться поле -- назвать фильтр. Если назвал, можешь сохранить как новую вкладку.
Там будет этот фильтр с уже настроенными параметрами. Если начинаешь изменять параметры, предлагает создать новый фильтр или изменить параметры текущего.
Нужно создать домен фильтра, плюс создать FilterEnvelop instanceof IFilter для единообразия методов поиска Entries.

У всех записей, которые написаны пользователем, должен быть соотв. флажок.

У всех записей, которые написаны пользователем, должен быть соотв. флажок.

Необходимо научиться деплоить в параллель с существующим топкупоном, не мешая ему, на девелопмент-серваке.
Поделить память, чтоб всем хватало.

Нужно переделать систему хранения авторов в записях.

• Нужно сохранять identity автора в формате, как мы аккаунтам идентити даём. То есть "тип провайдера:неменяемый айди". Это может пригодиться после для отслеживания консистентности, поиска френдов и тп.
• Нужно сохранять human-readable поле имени, которое после и показывать.

Соответственно модифицировать все доступаторы.

Надо перейти на монго, когда будет RC1 хотя бы у плагина. Это планируется на неделе.

Для лаконичного рендеринга мало только заголовка и картинки. Нужен короткий текст.

На домашней вкладке нужно текстовое поле с линейкой иконок под ним, которое позволило бы кликать по ним и шарить контент -- текст, картинки.

• Доступ к Evernote не работает на production
• С новым ключом нужно на production сделать провайдер апи не для песочницы -- токены соотв. получил

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

Если юзер не обращается к табу, перемешивая результаты фильтрами, он должен раз в const минут сделать запрос на сервер, нет ли новых сообщений. Как в старом твиттере.

1. Когда подсасываются записи, которые уже есть в базе (по идентифаеру), они должны обновляться.
2. Хорошо бы совсем старые записи тоже обновлять там, где это имеет смысл. Например, в evernote это должно быть вполне регулярно.

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

Все сообщения и тексты должны быть вынесены в i18n.

Нужно сделать список социальных медиа, к которым можем и хотим сделать доступы, и потихоньку эти доступы пилить. Минимум для добавления доступа и открытия нового релиза -- авторизация + пулл.

Нужно встроить YUI Compressor, чтобы он обжимал жаваскрипт и css в момент запуска на продакшне.
Может быть, какое-то такое решение уже есть.

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

Поле заголовок -- точно не заголовок.

Конкатенация описания и сообщения -- вряд ли панацея.

Нужно аккуратнее создавать записи.

Кроме того, работает ли категория "events"?

Доступ в Linked In сейчас даёт только авторизацию. Нужно разобраться, какими лентами пользуется народ в линкедине, можем ли мы подсосать личные сообщения и тд, сделать категории (ленты или-не) и теги (или-и), научиться парсить сообщения.

Когда докручиваешь до конца странички с записями, если есть ещё записи, подходящие по фильтру, должна быть кнопка типа "load more entries", которая подсосёт ещё страничку и добавит в конец ленты в табе.

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

• Он должен быть уникален и неизменяем. Логин в evernote подходит, screen_name в twitter -- нет.
• Уникальность ограничевает читаемость человеком. Нужно отдельное поле title в домене Access, чтобы хранить там имена табов. Это поле нужно давать аутентификацией.

Доступ к Facebook сейчас даёт только авторизацию. Нужно проанализировать, к каким лентам мы можем обращаться, сделать для них дефолтные категории, как в твиттере, и сделать парсер сообщений в Entries.

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

http://www.bennadel.com/blog/1810-Creating-A-Sometimes-Fixed-Position-Element-With-jQuery.htm

оч удобная штука. можно, например, табы так сделать.

Во многих accessor-ах есть методы, которые выбрасывают exception, если доступ просрочен. Сейчас обработка такого кейса не сделана или поражает уродством. Если можно это как-то сделать аннотациями, было б классно.

У всех записей дОлжно отслеживать, открыты они всем (видимы публично) или нет. Рассматривать только бинарно: публичны/нет. Но -- у всех записей.

Страница должна быть красивой, адекватной, отвечать концепции воронки продаж.

В том числе, должен быть яркий красный список просроченных доступов с предложением их продлить или удалить.

http://blog.springsource.com/2011/04/12/one-step-deployment-with-grails-and-cloud-foundry/

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

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

Многие ленты дают контент конкретного набора типов.

Например, твиттер: личные сообщения, твиты.

Фейсбук: фоточка, хтмль-текст, статус, видео, и тд.

Это константный набор, свой для каждого провайдера. Он по-разному возвращается АПИ, по-разному сохраняется в EntryEnvelop и рендерится.

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

Так как теперь есть ассигнейшн и майлстоуны, нужно реорганизовать лейблы. Они должны отражать:

• Тип и приоритет задачи (баг, блокер, ...)
• Структурная часть системы (ui, db, deployment, ...)
• Подпродукт, на который направлен тикет

Все лейблы должны иметь расшифровку в вики.

Нужно ссылкам из записей добавлять target="_blank" в автоматическом режиме. Может быть, жаваскриптом.

Многие ленты дают контент конкретного набора типов.

Например, твиттер: личные сообщения, твиты.

Фейсбук: фоточка, хтмль-текст, статус, видео, и тд.

Это константный набор, свой для каждого провайдера. Он по-разному возвращается АПИ, по-разному сохраняется в EntryEnvelop и рендерится.

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

Страничка mash не работает, так как запоминает настройки последнего доступа

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

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

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

На лайве не работает кнопка "Show Full Text". Возвращает 404 и молчит.

Вообще оно работало раньше, но почему-то перестало.

Задача: логи приложения начиная с уровня debug должны записываться в собственный файл аппликейшна.

Нужно определиться, что доступ, что управление доступом, что тип доступа, и тд.

У нас есть класс I18n, предназначение которого -- упростить ввод сообщений локализованных. Он позволяет сократить их в несколько раз, до I18n."message.code"()

• Почему-то иногда после простоя сайта это не работает. Заявленный в I18nBoot перехватчик отцепляется. Соответственно, ложится весь сайт.
• Почему-то I18n.metaClass.'static'.getProperty не работает, хотя было бы удобно не писать круглые скобки вообще.

Gmail даёт возможность юзать IMAP без логина-пароля, по специальному OAuth. Мне кажется, это обалденная штука, которую маст хэв.

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

В контроллере Access и в сервайсе AuthService не должно быть уверенности, что мы авторизуемся через OAuth. весь код, зависимый от метода авторизации, должен быть вынесен в... эээ... авторизаторы. По аналогии с тем, как сейчас объект сессии им передаётся для совершения OAuth авторизации.

Апи должно быть аккуратно описано в главном предке.

Все entries, когда в лентах, должны форматироваться, с одной стороны, однотипно: имя, заголовок, ссылка, дата, значок источника, картинка и тп. С другой стороны, различно: твиттер накладывает свои ограничения, что-то другое -- свои.
Нужен простой метод организации рендеринга entry. Дёшево добавлять, сопровождать фрагменты.
Сейчас это набор <g:if>.

Лучше всего научиться юзать urls.io, но не только -- и всех ключевых тоже. bit.ly, is.gd и тп.

У твиттера есть разные типы сообщений: это обычные твиты и личные мессаги.
Это как-то должно отражаться на базе данных. Сообщения должны обрабатываться по-разному, иметь разное identity, адрес, по-разному рендериться.

Доступ (и доступатор) должен уметь давать список всех kind'ов, чтобы по ним можно было фильтровать. (мб как enum)

Соотв. образом нужно изменить фильтр. Kind обрабатывать как KindEnvelop, без домена.

Гугл отдаёт емейл. Фейсбук тоже может.
Это априори подтверждённые адреса.
Нужно их коллекционировать в какую-нибудь табличку (или в список строчек, если монго поднимем)

Нужно уметь не только подсосать текст, который даётся в записи (например, аннотацию RSS), но и, если это возможно, страничку оригинала. Резать ей head, script, iframe и тд, чистить, оформлять для удобного чтения, возвращать юзеру.

Делать только по запросу, по возможности -- на клиент-сайд.