Автор говорит о последней сессии YC для инвесторов (42Floors — YC startup). действительно, последняя сессия была очень интересной для — было около 500 инвесторов. но в целом (и особенно — в РФ) все далеко не так хорошо.
Да, это скорее терминологический вопрос — в см. это уже не ORM, т.к. сложных преобразований (в том числе и для запросов) NoSQL-клиенты не делают. Как правило, все сводится к change tracking и сериализации.
Вот это как раз неверно :) В см. как правило, там не нужен ORM, т.к. в БД можно сохранять объекты «как есть». Соответственно, не нужен маппинг, сложные преобразования запросов и т.п.
Т.е. те плюсы, которые дает ORM РСУБД-разработчикам, NoSQL-разработчики получают от client-side API.
И, раз уж здесь была затронута тема о том, что стоит выносить на уровень БД, озвучу свое мнение:
IMO, лучше всеми возможными способами избегать использование хранимых процедур, триггеров и прочего кода на SQL, сильно связанного с логикой работы приложения. Причин тому несколько, вот главные из них:
— Сложный код на SQL (все, что не является запросом) — ужасен. Его отладка, профайлинг и поддержка (ревизии в репозитории и т.п.) в разы дороже, чем в случае с кодом на любом современном языке.
— То, что код, работающий в процессе БД спасет вас в случае роста нагрузки — миф. Скорее спасет partitioning / sharding, и денормалиация (пример: goo.gl/dN7tl ). И конечно же, разработчики, хорошо понимающие, чем отличается full scan от index seek.
Почитал все комментарии — выводы:
— отношение к ORM-решениям у разных людей может быть совершенно разное — все очень сильно зависит от опыта работы с конкретными решениями и специфики проектов, над которыми они работали.
— очень многие из этих людей готовы отстаивать свою точку зрения, несмотря на понимание того, что единой точки зрения тут явно быть не может :) (все очень сильно зависит от массы факторов).
На мой взгляд, что ORM обычно эффективны в сценариях, когда скорость разработки очень важна. На мой взгляд, связь примерно такая:
— Если производительнось исключительно важна (вы делаете облачный сервис, который будет обслуживать миллионы клиентов), вероятно, вам лучше отказаться от сложных ORM, а возможно, и от SQL DB вообще. Ваши лучшие друзья — memcached, Redis, C++ и т.п., т.к. расходы на разработку в данном случае могут быть нивелированы расходами на эксплуатацию.
— Если для вас крайне важна скорость разработки — берите любое более-менее известное ORM-решение, использование которого в вашем конкретном случае даст максимальный эффект. В производительности вы потеряете не так уж и много, но заметно ускорите сам процесс разработки.
В промежуточном сенарии я бы все же выбрал ORM, но пользовался бы SOA/DTO для реализации уровня абстракции, т.е. заранее предусмотрел бы возможность отказа как от ORM, так и от текущей БД.
Возможно, ответ слегка biased, т.к. я — один из разработчиков DataObjects.Net.
> Саша, чтобы кастомерам было интересно регистрироваться на сайте, то нужно им дать инструмент для демонстрации своей длинной пиписьки.
Мы этим как раз сейчас и занимаемся :)
> Чтобы привлечь какой-либо значимый бренд к акциям необходима аудитория, а аудитория не появится, пока нет брендов. Таким образом 9facts загоняется опять в ситуацию «курица-яйцо»
Мы планируем поступить так:
— Договориться с 10-15 компаниями о проведении акций. Первые рекламодатели получат значительные преференции (в частности, возможность проводить конкурсы в течение первого года бесплатно).
— Запустить все акции одновременно. В их интересах анонсировать все это максимально широко, т.к. тогда о каждой акции узнает ~ в 1-015 раз большая аудитория.
— Если все это пройдет достаточно гладко, о сервисе расскажут и компании, чьи метрики мы позволяем конвертировать в деньги. Это позволит нам собрать еще в несколько раз больше людей.
Мне все это кажется логичным, но как будет на самом деле — сказать сложно. Самое сложное сейчас — договориться с первыми компаниями.
> А еще крупные конторы никогда не делятся брендом за бесплатно.
Это верно, поэтому пока мы можем расчитывать только на средние и мелкие. На всех, кто захочет быстро продвинуть какой-то из своих продуктов среди достаточно интересной ЦА, практически не трятя на это денег.
> P.S. В детстве мама сравнивала меня с одним отличником. Терпеть этого не мог.
Возможно, это таки сделало вас лучше :) Я так же плевать хотел на сравнения оценок — участие в олимпиадах по паре предметов было для меня много более значимым. Но суть это не сильно меняет.
Наша цель — дать возможность каждому показать, чем он выделяется среди прочих.
Связь между косвенными метриками и достигнутыми результатами есть правктически всегда. Досаточно взглянуть на топы Твиттера (Stack Overflow, Klout и т.п.) и узнать чуть больше о людях, у которых много подписчиков.
Кроме того, мы же не предлагаем _не смотреть_ на реальные результаты. Во многих случаях они так же измеримы — я уже писал про людей из отделов продаж, техподдержки, маркетинга и т.п., но ясно, что всего сразу нам не охватить, и начинать надо с тех метрик, которые мы в состоянии собрать.
Если удастся привлечь аудиторию, которой интересны косвенные метрики, со временем удастся и все остальное (API и группы пользователей сделают все сами). Собственно, в этом и стстоит наша ближайшая цель — сделать поддержку минимального набора косвенных метрик и показать пользователям, что если они публикуют их у нас, они только выигрывают от этого.
Идея в том, чтоб фиксировать все маломальски значимые достижения в одном месте. Получил сертификат, щелкнул на ссылку, и он у нас, + указан итоговый балл, а заодно и сравнил себя с другими людьми, получившими такой же.
Кроме того, к нам могут поступать данные, характеризающие тебя в реальном времени: 9facts.com/User/Top?Interval=LastMonth&KeywordId=4&term=rescue — это данные из RescueTime о рабочем времени, производительности и т.п. Пока поддержка подобных сервисов сделана не на лучшем уровне — мы фиксируем точки, а нужно весь графиг изменения величины целиком. Но в целом ясно, что это позволяет сравнивать людей в реальном времени внутри компаний, отделов и так далее (по объему продаж, количеству закрытых заявок в службу техподдержки и т.п.).
Итак,
— Призы и скидки от самых разных компаний для пользователей с высоким рейтингом в городе или стране — то, что мы сделаем в ближайшее время. ~ Как Групон, только не для всех.
— Т.к. мы знаем о людях самое интересное, вероятно, будет мобильное приложение, позволяющее находить и общаться с интересными людьми вблизи вас.
Вот это как раз неверно :) В см. как правило, там не нужен ORM, т.к. в БД можно сохранять объекты «как есть». Соответственно, не нужен маппинг, сложные преобразования запросов и т.п.
Т.е. те плюсы, которые дает ORM РСУБД-разработчикам, NoSQL-разработчики получают от client-side API.
IMO, лучше всеми возможными способами избегать использование хранимых процедур, триггеров и прочего кода на SQL, сильно связанного с логикой работы приложения. Причин тому несколько, вот главные из них:
— Сложный код на SQL (все, что не является запросом) — ужасен. Его отладка, профайлинг и поддержка (ревизии в репозитории и т.п.) в разы дороже, чем в случае с кодом на любом современном языке.
— То, что код, работающий в процессе БД спасет вас в случае роста нагрузки — миф. Скорее спасет partitioning / sharding, и денормалиация (пример: goo.gl/dN7tl ). И конечно же, разработчики, хорошо понимающие, чем отличается full scan от index seek.
— отношение к ORM-решениям у разных людей может быть совершенно разное — все очень сильно зависит от опыта работы с конкретными решениями и специфики проектов, над которыми они работали.
— очень многие из этих людей готовы отстаивать свою точку зрения, несмотря на понимание того, что единой точки зрения тут явно быть не может :) (все очень сильно зависит от массы факторов).
На мой взгляд, что ORM обычно эффективны в сценариях, когда скорость разработки очень важна. На мой взгляд, связь примерно такая:
— Если производительнось исключительно важна (вы делаете облачный сервис, который будет обслуживать миллионы клиентов), вероятно, вам лучше отказаться от сложных ORM, а возможно, и от SQL DB вообще. Ваши лучшие друзья — memcached, Redis, C++ и т.п., т.к. расходы на разработку в данном случае могут быть нивелированы расходами на эксплуатацию.
— Если для вас крайне важна скорость разработки — берите любое более-менее известное ORM-решение, использование которого в вашем конкретном случае даст максимальный эффект. В производительности вы потеряете не так уж и много, но заметно ускорите сам процесс разработки.
В промежуточном сенарии я бы все же выбрал ORM, но пользовался бы SOA/DTO для реализации уровня абстракции, т.е. заранее предусмотрел бы возможность отказа как от ORM, так и от текущей БД.
Возможно, ответ слегка biased, т.к. я — один из разработчиков DataObjects.Net.
Мы этим как раз сейчас и занимаемся :)
> Чтобы привлечь какой-либо значимый бренд к акциям необходима аудитория, а аудитория не появится, пока нет брендов. Таким образом 9facts загоняется опять в ситуацию «курица-яйцо»
Мы планируем поступить так:
— Договориться с 10-15 компаниями о проведении акций. Первые рекламодатели получат значительные преференции (в частности, возможность проводить конкурсы в течение первого года бесплатно).
— Запустить все акции одновременно. В их интересах анонсировать все это максимально широко, т.к. тогда о каждой акции узнает ~ в 1-015 раз большая аудитория.
— Если все это пройдет достаточно гладко, о сервисе расскажут и компании, чьи метрики мы позволяем конвертировать в деньги. Это позволит нам собрать еще в несколько раз больше людей.
Мне все это кажется логичным, но как будет на самом деле — сказать сложно. Самое сложное сейчас — договориться с первыми компаниями.
> А еще крупные конторы никогда не делятся брендом за бесплатно.
Это верно, поэтому пока мы можем расчитывать только на средние и мелкие. На всех, кто захочет быстро продвинуть какой-то из своих продуктов среди достаточно интересной ЦА, практически не трятя на это денег.
Возможно, это таки сделало вас лучше :) Я так же плевать хотел на сравнения оценок — участие в олимпиадах по паре предметов было для меня много более значимым. Но суть это не сильно меняет.
Наша цель — дать возможность каждому показать, чем он выделяется среди прочих.
Кроме того, мы же не предлагаем _не смотреть_ на реальные результаты. Во многих случаях они так же измеримы — я уже писал про людей из отделов продаж, техподдержки, маркетинга и т.п., но ясно, что всего сразу нам не охватить, и начинать надо с тех метрик, которые мы в состоянии собрать.
Если удастся привлечь аудиторию, которой интересны косвенные метрики, со временем удастся и все остальное (API и группы пользователей сделают все сами). Собственно, в этом и стстоит наша ближайшая цель — сделать поддержку минимального набора косвенных метрик и показать пользователям, что если они публикуют их у нас, они только выигрывают от этого.
Кроме того, к нам могут поступать данные, характеризающие тебя в реальном времени:
9facts.com/User/Top?Interval=LastMonth&KeywordId=4&term=rescue — это данные из RescueTime о рабочем времени, производительности и т.п. Пока поддержка подобных сервисов сделана не на лучшем уровне — мы фиксируем точки, а нужно весь графиг изменения величины целиком. Но в целом ясно, что это позволяет сравнивать людей в реальном времени внутри компаний, отделов и так далее (по объему продаж, количеству закрытых заявок в службу техподдержки и т.п.).
P.S. Про призы и скидки очень подробно написано в разделе Pivot.
— Призы и скидки от самых разных компаний для пользователей с высоким рейтингом в городе или стране — то, что мы сделаем в ближайшее время. ~ Как Групон, только не для всех.
— Т.к. мы знаем о людях самое интересное, вероятно, будет мобильное приложение, позволяющее находить и общаться с интересными людьми вблизи вас.