Я наверное лет 6 (или больше уже) сидел на гугл ридере, в том числе на мобильной его версии. У меня порядка 400 подписок (~200 сообщений в день). Пробовал фидли — мобильный клиент при плохом интернете (в метро) работает отвратительно.
В итоге перешел на Reeder reederapp.com — очень доволен. И мобильное приложение и десктопный клиент просто отличные.
Правда reeder изначально был сильно завязан на api google reader'а, но сейчас уже есть альтернатива в виде feedbin.me/, и дальше автор обещает добавить поддержку еще пары подобных сервисов для синхронизации.
Приложение выглядит современно и симпатично.
От делать нечего накидал несколко мелких замечаний и придирок. Вдруг пригодится :)
Надпись Россия что означает? Можно поменять? Она определяется моим текущим местоположением? А если можно поменять, то покажите это как-то. Например маленькой стрелочкой-треугольничком слева или справа от нее.
Кнопка Демо слишком большая и слишком близко к кнопке Вход. Можно случайно нажать мимо.
А что делать если я забыл, потерял, не знаю логин/пароль? Я думаю стоит явно разместить ссылку с этой информацией. Возможно она скрывается в правом нижнем углу за кнопкой (i), но это совершенно не очевидно. А ее не с первого раза нашел.
Время работы важная информация при выборе банкомата — я бы показал его сразу в списке.
Сходу не понятно что означают зеленый, серый и темно-серый кружки.
Где строка поиска? А если я в Москве, но хочу посмотреть банкоматы в Питере? Куда вбивать адрес, район, город, страну в конце-концов? Не на карте же искать самому?
Зеленую статус-полоску «Банкомат в настоящее время работает» я бы объединил с временем работы. И писал бы более человеческим языком. Например: «Время работы: с 9:00 до 21:00. Сейчас работает» и зеленым цветом выделить.
В правой панельке самое важное — это расположение банкомата на карте. Стоит показывать сразу кусок карты с маркером, и дополнительно, при желании, можно нажать кнопку [Построить маршрут]. Избавите от лишнего клика и ожидания построения маршрута. А карту можно показывать в виде статической png-картинки и кешировать. Тогда не понадобится интернет для ее просмотра.
Слово «Ближайший» 3 раза повторяется в верхнем меню. Можно заменить на просто Банкомат, Отделение, Ближайшие скидки, Погашение кредита.
“Another thing to know about implicit parameters is that they are perhaps most often used to provide information about a type mentioned explicitly in an earlier parameter list, similar to the type classes of Haskell”
Типа частный случай implicit параметров, которые предоставляют расширенную информацию о предыдущих аргументах функции. Если я правильно понял)
Ну. Видимо у всего есть цена.
Мы в основном используем нативные скалавские библиотеки (akka, squeryl, scalatra) и практически не имеем подобных проблеммы. Используем джавайский protobuf и там да, приходится заботится о конвертации коллекций, но, как вы уже сказали, имплисит спасает.
Для многих библиотек уже есть удобные скалавские обертки, а если для чего-то еще нет — это хороший повод ее сделать :). хотя бы just for fun.
Хотя с hibernate я думаю это будет не просто.
А в чем конкретно заключается проблемма интеграции с Java'шными либами?
Может поделитесь опытом или ссылкой где об этом почитать.
В своей работе ни разу не наткнулись на какие-нибудь подобные проблеммы. Может нам просто везет пока? :)
The first query will be SELECT * FROM application. Then NotORM stores the information about used columns to the cache and all next requests will issue SELECT id, title FROM application. If you change the script and add more columns then one extra SELECT * will be issued and all next queries will be optimal again.
Очень интересный подход. Надо поизучать повнимательнее.
Т.е. они анализируют паттерн использования и кешируют. Такой себе JIT прямо:)
Тут все очень сильно зависит от. Подобный «ум» иногда помогает. Но создает очень непредсказуемое поведение.
А что если нам будет нужно достать 100500 объектов $book, и только у первых 5ти вывести теги? Как об этом догадается ОРМ?
Есть любопытный момент в этом примере.
Если смотреть только на этот кусок шаблона, то кажется что он должен сделать N+1 запросов к БД, т.к. в цикле дергает $book->related('book_tag')
Но! Но в документации написано что будет выполнен один запрос за тегами:
SELECT `book_id`, `tag_id` FROM `book_tag` WHERE (`book_tag`.`book_id` IN (1, 4, 2, 3))
Как? Как они это делают? И если действительно делают, то одно это достойно уважения.
Теоретически они должны пробросить в $book контекст выполнения, чтобы метод related понимал что стоит сразу достать все теги для всех результатов запроса $database->table('book')->order('title')->limit(5)
там мультипроцессорность реализуется тремя способами (на выбор):
1. через запуск отделных процессов через popen()
2. через tcp сокеты stream_socket_client()
3. через pcntl_fork() // не доделано
В основном я пользовался popen как самым надежным и прозрачным способом. сокеты использовлись коллегами для дебага под виндой. а форки так и не доделал.
Самый главный вопрос: как наиболее оптимально организовать обмен данными между родителем и потомком. По завершению работы в потомке складывать ответ во временный файл, а родитель из него потом все считывает? Пожалуй надо так и сделать. :)
scalikejdbc ближе всего к тому, что описано в данном посте. Я думаю его query DSL можно было бы дописать до необходимого уровня поддержки этих фич.
Опять же вот есть scalikejdbc-async — https://github.com/scalikejdbc/scalikejdbc-async/tree/develop
В итоге перешел на Reeder reederapp.com — очень доволен. И мобильное приложение и десктопный клиент просто отличные.
Правда reeder изначально был сильно завязан на api google reader'а, но сейчас уже есть альтернатива в виде feedbin.me/, и дальше автор обещает добавить поддержку еще пары подобных сервисов для синхронизации.
Очень рекомендую, да.
Mac/iOS only ;)
От делать нечего накидал несколко мелких замечаний и придирок. Вдруг пригодится :)
тогда уж и вот тут:
implicit val personNameComparator = Comparator[Person] {
наверное нужно new поставить:
implicit val personNameComparator = new Comparator[Person] {
stackoverflow.com/a/2982293
перепутал
[T : Comparator]
с[T <: Comparator]
Чувствуется java бэкграунд :). Так в скале не пропрет.
Видимо имелось в виду
def compare(onePerson: Person, anotherPerson: Person): Int
Типа частный случай implicit параметров, которые предоставляют расширенную информацию о предыдущих аргументах функции. Если я правильно понял)
Мы в основном используем нативные скалавские библиотеки (akka, squeryl, scalatra) и практически не имеем подобных проблеммы. Используем джавайский protobuf и там да, приходится заботится о конвертации коллекций, но, как вы уже сказали, имплисит спасает.
Для многих библиотек уже есть удобные скалавские обертки, а если для чего-то еще нет — это хороший повод ее сделать :). хотя бы just for fun.
Хотя с hibernate я думаю это будет не просто.
Может поделитесь опытом или ссылкой где об этом почитать.
В своей работе ни разу не наткнулись на какие-нибудь подобные проблеммы. Может нам просто везет пока? :)
Очень интересный подход. Надо поизучать повнимательнее.
Т.е. они анализируют паттерн использования и кешируют. Такой себе JIT прямо:)
А что если нам будет нужно достать 100500 объектов $book, и только у первых 5ти вывести теги? Как об этом догадается ОРМ?
Если смотреть только на этот кусок шаблона, то кажется что он должен сделать N+1 запросов к БД, т.к. в цикле дергает $book->related('book_tag')
Но! Но в документации написано что будет выполнен один запрос за тегами:
Как? Как они это делают? И если действительно делают, то одно это достойно уважения.
Теоретически они должны пробросить в $book контекст выполнения, чтобы метод related понимал что стоит сразу достать все теги для всех результатов запроса $database->table('book')->order('title')->limit(5)
А если мы бы хотели сделать что-то типа:
Он тоже достанет все теги для всех найденных книг? Или догадается что тут нам нужны только теги первой?
там мультипроцессорность реализуется тремя способами (на выбор):
1. через запуск отделных процессов через popen()
2. через tcp сокеты stream_socket_client()
3. через pcntl_fork() // не доделано
В основном я пользовался popen как самым надежным и прозрачным способом. сокеты использовлись коллегами для дебага под виндой. а форки так и не доделал.
Самый главный вопрос: как наиболее оптимально организовать обмен данными между родителем и потомком. По завершению работы в потомке складывать ответ во временный файл, а родитель из него потом все считывает? Пожалуй надо так и сделать. :)