Насчет контактов и объединения — написал в статье, что так в итоге и сделал. Претензия моя была такая: зачем иметь read-only контакт вообще? Сделай из него полноценный контакт на базе скайповского и позволь пользователю его менять как угодно. И объединять.
Автор, ваш редактор прекрасен и, скорее всего, вы умеете в нем строгать анимированные GIFы со скоростью света, но, мне кажется, вы не поняли своих оппонентов.
Ваш редактор — это динозавр. Динозавр вымерли не потому, что были «плохими». Просто их пищевая цепочка оказалась разрушена. Они _устарели_.
Так и ваш редактор. 25 лет назад он прошел бы просто «на ура». Уверен, что фидо наполнилось бы восторженными криками счастливых обладателей этого чуда. Но мир изменился. И современные интерфейсы созданы кровью, вытекшей из глаз пользователей и разработчиков.
Одним словом, проблема в том, что ваши интерфейсные идеи имеют более эффективные аналоги.
Идея ограничить кол-во используемых клавиш, чтобы обходится без мышки, не является «плохой». Но она является неэффективной по сравнению с другими идеями. Она — динозавр. Лучше, например, встроить терминал, который позволит набирать и исполнять команды некоторого скриптового языка.
Идея грузить пользователя виртуальным представлением о том, что есть некий невидимый буфер, который пользователь воображает (но не видит) и это позволяет решать какие-то задачи — тоже динозавр. Т.е. это работает до момента, когда не появится идея лучше. Идея лучше — это, например, те же слои, которые видны стопочкой, которые легко понять и использовать, не напрягая воображение.
Нелепые цветные иконки, излишне большие или маленькие поля для клика, неразумная трата экранного места и пр. — все это можно улучшить. Это работает, да. Никто не спорит. Но можно сделать лучше.
Резюме: если вы возьмете на вооружение современные представления об интерфейсах, то сможете ваш функционал обернуть в «фантик интерфейса», который a) будет ближе и понятней современному пользователю b) выглядеть эстетичней c) повысить эффективность.
И тогда аудитория вашей программы увеличится, что позволит получить больше обратной связи и прочих плюшек.
Нельзя сказать, что подобный дизайн плох, его просто не ожидаешь от Apple с ее инновационными идеями.
Control Center явно украден позаимствован — но разве это плохо? И добавили приятную фишку — подсветку под текущее приложение.
Apple идет по пути упрощения дизайна — трудно упрекать ее в том. Попробуй придумай 100500 секвеморфных обложек под каждое приложение. А с новым дизайном это все делается проще, главное из цветовой палитры не выпасть.
И еще мне кажется, все-таки это не самый последний, окончательный вариант дизайна и Apple отреагирует на критику и немного переделает иконки и цвета. Уж больно топорными выглядят некоторые иконки.
Больше всего мне в iOS не нравится именно клава. Она не терпит быстрого набирания, а я не люблю долго печатать. Надеялся, что в iOS 7 появится аналог swipe или может еще что-то, но, видно, не судьба… (
У вас на сайте написано «ultra-fast database». Или нет? :)
Вот и прошу — покажите сравнительные тесты, пожалуйста. Что вас так удивляет в этом вопросе? Или измените позиционирование, то есть напишите «медленная, но много возможностей»
:-)
Ссылки на опыт отдельных пользователей, конечно, интересен. Но обычные сравнительные тесты сработали бы намного лучше. Потому что — мало ли насколько криворукий пользователь, верно? :)
Кеш компенсирует тем что записав много записей на 50 страниц в мозгах как бы не важно как ты их там записал — построчно или по колонкам. Затем 50 страниц лягут на диск. Если пытаться флушить каждую запись да можно получить деградацию.
То есть приемлемая производительность достигается только при отказе от гарантий транзакционности и риске потери данных по отключению питания. При гарантиях сохранности (отключении файлового кэша) вставка на порядки медленнее, чем в сравнимых реляционных БД.
Так?
Но опять же, разве скорость инсертов самая важная фишка реляционки? А я думал поиски, джойны, агрегации.
У ваших пользователей базы всегда в режиме readonly? :-)
Еще раз повторю, что Валентина создавалась, чтоб работать не только с таблицами, но и со связями. У нас можно не делать, и обычно их никто и не делает, первичные ключи. Можно даже не делать вторичные. Схема базы получается проще. Запросы тоже могут быть короче. Идея самой Валентины родилась когда я лично еще в далеких 90х познакомился с ОО и С++, а потом с реляционками… Стало грустно. Хотелось чего то более умного, как С++ умней чем Си. И скорость вообще была не самоцель. Наоборот, даже были готовы на жертвы. Но так получилось… что почему то практически все кто пробовал Валентину — говорили, что быстрей. И колонки в Валентине, еще в 95 году, делались вовсе не для скорости.
Истоки вашего решения и мотивация понятна. Просто меня удивляет — вы не замечаете, что мир не стоял на месте с той поры? :) В текущей ситуации какие резоны пользоваться вашей БД? Грубо говоря, можете мне привести сценарий, где, скажем, SQLite не подходит, а Valentina DB — еще как. Если, конечно, у вас есть такое желание.
Ну это все вопросы про Valentina Database, а не про Valentina Studio да? Так что лучше обсудить это будет в другом месте. Но кое что отвечу.
Ну этот пост является скрытой рекламой Valentina DB, как я понимаю? :) Потому и вопросы.
* Вы можете PostgreSQL встроить в свою программу как embedded engine? не можете. Для этого применяется зачастую SQLite в последние годы. Ранее было гораздо больше таких движков.
* Почему у вас тенденция смотреть на самые дорогие позиции? ADK — обычно покупают под одну IDE/language, такие как REALbasic, LiveCode. Обычно людей интересуют именно кросс-платформенность. В таком случае это стоит 199$ на одну платформу, 399$ на все три. За $999 девелопер получит целую гору наших ADK под все языки что есть у нас (C C++ ObjC RB, LiveCode, .NET, COM, PHP, ...)
Правда, из ваших ответов ничего не понял опять. Какие преимущества встраивать вашу БД по сравнению с Sqlite? Насколько полная поддержка SQL 92? Как гарантируется целостность транзакций? Могут ли несколько писателей БД работать с ней одновременно? Может есть какая-то (секретная) ссылка, где можно узнать подробней?
Или единственное преимущество в том, что есть еще и сервер? Вы уверены, что все встраиваемые БД — это всегда промежуточная фаза перед клиент-серверным этапом? Для SQLite есть сервер: www.sqlabs.com/cubesql.php
А если человек хочет в своей программе иметь и локальную базу и сервер — то юсать лайт + my/postgre — это может превратится в те еще танцы. Многие девелоперы радуется именно этой возможности в Валентине.
Может 500 лет назад — да. Были бы сложности. Но сейчас утверждать, что трудно в одном приложении использовать несколько БД это… несколько наивно. Вы слышали про FireDAC, например?
И, опять-таки, повторюсь — Sqlite и PostgreSQL — БЕСПЛАТНЫ. Зачем платить вам? Какие выгоды?
* поверьте это миф что колончатая базы проиграет на инсертах. Кеш компенсирует. Ну только на таблицах с сотнями колонок да можно увидеть деградацию, но на обычных 10-50 колонок нет. А учитывая что Valentina не только SQL но и, как счас говорят Non-SQL движок — можно через наше Valentina API получить еще многократное ускорение по отношению к SQL. Пример сходу из памяти, таблица 19 колонок, все типы что есть, 100К записей без индексов добавляются через айпи в 3,5 секунды на старндартном маке (пару лет назад смотрели), SQL давал 20 с байдингом, 80 без байдинга.
Хоть меня убей, но я не понимаю, как кэш может компенсировать необходимость обновлять N (N=кол-во столбцов) списков в сравнении с одним списком (традиционная СУБД). Или у вас на диске данные не хранятся последовательно по колонкам?
100 k / 3.5 сек = 28 тыс вставок в секунду?
Прогнал тест на вставку в SQLite. Компьютер: Windows x64 7 (Intel i5-2300, 2.8 Ghz), HDD.
6 столбцов ~ 160 тыс записей в секунду, 12 ~ 115 тыс, 24 ~ 70 тыс. Синхронизация на ОС.
* насчет ни одного отзыва Вы перегибаете думаю. Кстати у нас же на сайте в разделе User Testimonials кое что есть. Там дядя сравнивает как раз Cocoa -> Coredata -> SQLite.
Имел в виду независимый отзыв.
Сомнителен или не сомнителен — нам нравится развивать наше собственное оружие. Да я часто люблю сравнивать СУБД и компиляторы как оружие. Кто то его разрабатывает, а кто то применяет. Если нам нравится создавать свою ракету — в чем вы видите проблему?
На основании сайта. На котором общие фразы про " blazingly fast, most advanced" и ни одного конкретного примера производительности. Интересные результаты по скорости есть у всех columnar db — когда считается агрегат по колонке. А когда вставляется новая запись во сколько раз быстродействие «неинтереснее» обычных RDBMS? :-)
Позиционирование тоже… туманно :) Это встраиваемая БД за $999 (Valentina DB ALL ADK $999.99 )? Серьезно?
Или это RDBMS за $1500? Чем лучше бесплатного PostgreSql?
Поставил Screen Notifications — включает экран на 10 секунд при новом уведомлении. Понравилось.
Насчет контактов и объединения — написал в статье, что так в итоге и сделал. Претензия моя была такая: зачем иметь read-only контакт вообще? Сделай из него полноценный контакт на базе скайповского и позволь пользователю его менять как угодно. И объединять.
Первоисточник этих идей и не только их.
Автор, ваш редактор прекрасен и, скорее всего, вы умеете в нем строгать анимированные GIFы со скоростью света, но, мне кажется, вы не поняли своих оппонентов.
Ваш редактор — это динозавр. Динозавр вымерли не потому, что были «плохими». Просто их пищевая цепочка оказалась разрушена. Они _устарели_.
Так и ваш редактор. 25 лет назад он прошел бы просто «на ура». Уверен, что фидо наполнилось бы восторженными криками счастливых обладателей этого чуда. Но мир изменился. И современные интерфейсы созданы кровью, вытекшей из глаз пользователей и разработчиков.
Одним словом, проблема в том, что ваши интерфейсные идеи имеют более эффективные аналоги.
Идея ограничить кол-во используемых клавиш, чтобы обходится без мышки, не является «плохой». Но она является неэффективной по сравнению с другими идеями. Она — динозавр. Лучше, например, встроить терминал, который позволит набирать и исполнять команды некоторого скриптового языка.
Идея грузить пользователя виртуальным представлением о том, что есть некий невидимый буфер, который пользователь воображает (но не видит) и это позволяет решать какие-то задачи — тоже динозавр. Т.е. это работает до момента, когда не появится идея лучше. Идея лучше — это, например, те же слои, которые видны стопочкой, которые легко понять и использовать, не напрягая воображение.
Нелепые цветные иконки, излишне большие или маленькие поля для клика, неразумная трата экранного места и пр. — все это можно улучшить. Это работает, да. Никто не спорит. Но можно сделать лучше.
Резюме: если вы возьмете на вооружение современные представления об интерфейсах, то сможете ваш функционал обернуть в «фантик интерфейса», который a) будет ближе и понятней современному пользователю b) выглядеть эстетичней c) повысить эффективность.
И тогда аудитория вашей программы увеличится, что позволит получить больше обратной связи и прочих плюшек.
Control Center явно
украденпозаимствован — но разве это плохо? И добавили приятную фишку — подсветку под текущее приложение.Apple идет по пути упрощения дизайна — трудно упрекать ее в том. Попробуй придумай 100500 секвеморфных обложек под каждое приложение. А с новым дизайном это все делается проще, главное из цветовой палитры не выпасть.
И еще мне кажется, все-таки это не самый последний, окончательный вариант дизайна и Apple отреагирует на критику и немного переделает иконки и цвета. Уж больно топорными выглядят некоторые иконки.
Вот и прошу — покажите сравнительные тесты, пожалуйста. Что вас так удивляет в этом вопросе? Или измените позиционирование, то есть напишите «медленная, но много возможностей»
:-)
Ссылки на опыт отдельных пользователей, конечно, интересен. Но обычные сравнительные тесты сработали бы намного лучше. Потому что — мало ли насколько криворукий пользователь, верно? :)
То есть приемлемая производительность достигается только при отказе от гарантий транзакционности и риске потери данных по отключению питания. При гарантиях сохранности (отключении файлового кэша) вставка на порядки медленнее, чем в сравнимых реляционных БД.
Так?
У ваших пользователей базы всегда в режиме readonly? :-)
Истоки вашего решения и мотивация понятна. Просто меня удивляет — вы не замечаете, что мир не стоял на месте с той поры? :) В текущей ситуации какие резоны пользоваться вашей БД? Грубо говоря, можете мне привести сценарий, где, скажем, SQLite не подходит, а Valentina DB — еще как. Если, конечно, у вас есть такое желание.
Ну этот пост является скрытой рекламой Valentina DB, как я понимаю? :) Потому и вопросы.
Правда, из ваших ответов ничего не понял опять. Какие преимущества встраивать вашу БД по сравнению с Sqlite? Насколько полная поддержка SQL 92? Как гарантируется целостность транзакций? Могут ли несколько писателей БД работать с ней одновременно? Может есть какая-то (секретная) ссылка, где можно узнать подробней?
Или единственное преимущество в том, что есть еще и сервер? Вы уверены, что все встраиваемые БД — это всегда промежуточная фаза перед клиент-серверным этапом? Для SQLite есть сервер: www.sqlabs.com/cubesql.php
Может 500 лет назад — да. Были бы сложности. Но сейчас утверждать, что трудно в одном приложении использовать несколько БД это… несколько наивно. Вы слышали про FireDAC, например?
И, опять-таки, повторюсь — Sqlite и PostgreSQL — БЕСПЛАТНЫ. Зачем платить вам? Какие выгоды?
Хоть меня убей, но я не понимаю, как кэш может компенсировать необходимость обновлять N (N=кол-во столбцов) списков в сравнении с одним списком (традиционная СУБД). Или у вас на диске данные не хранятся последовательно по колонкам?
100 k / 3.5 сек = 28 тыс вставок в секунду?
Прогнал тест на вставку в SQLite. Компьютер: Windows x64 7 (Intel i5-2300, 2.8 Ghz), HDD.
6 столбцов ~ 160 тыс записей в секунду, 12 ~ 115 тыс, 24 ~ 70 тыс. Синхронизация на ОС.
Имел в виду независимый отзыв.
В неадекватном позиционировании.
Позиционирование тоже… туманно :) Это встраиваемая БД за $999 (Valentina DB ALL ADK $999.99 )? Серьезно?
Или это RDBMS за $1500? Чем лучше бесплатного PostgreSql?
Ни одного отзыва в Сети.
Удачи, конечно, но путь ваш сомнителен…