Это и хотел. Но как мне его теперь заново зарегистрировать? Не буду же я еще один аккаунт на Google заводить на еще один gmail-адрес? Я деактивировать этот, точнее, удалить как-то не особо вышло…
Но смысл следующих действий мне уже понятен, спасибо.
Странно то, что девочка в соседнем отделе по работе регистрирует там постоянно клиентов и у нее нужный пункт есть в списке. Правда, она заводить все аккаунты с нуля.
А я и говорю, что пользуюсь без проблему другими сервисами.
Напишите официальное письмо на имя руководства, что ответственные за проект являются некомпетентными лицами в этом вопросе. Естественно, с разъяснением, почему и как.
У вас будет шанс как выиграть конкурс, так и помочь общему делу развития качества проектов.
Я бы так не сказал. Такое можно сказать про Picasa или Яндекс.Фотки, вот уж где действительно бесплатного места навалом и куда фотки льются прямо с фотоаппарата.
На Фликре как раз ограничение в 200 фото заставляет многих выкладывать на все подряд, а избранное. Я придерживаюсь такой позиции и пока накопил лично лишь 47 items. Да и другие друзья там тоже выкладывают именно избранное.
Второй вопрос не по адресу, я лично не принимаю решения.
Планы в какой-то степени большие, но далеко загадывать бы не хотелось, потому что надо будет действовать по обстоятельствам. Я заинтересован в сообществе, которое будет как принимать участие в разработке системы, так и в ее использовании для разработки своих веб-проектов.
Я лично очень редко пользуюсь интерфейсом самого RememberTheMilk. У меня в Gmail включен Gadget, в котором я оперирую всей инфой. Очень удобно в боковой панельке.
Напоминания по СМС мне не нужны, т.к. все события синхронизируются на HTC, который всегда со мной.
Нам кажется, что наш продукт будет интересен сообществу профессиональных разработчиков. Мы много сил потратили на разработку Mozart, и у нас большие планы по развитию системы. Формат открытых исходных кодов кажется нам наиболее правильным с точки зрения популяризации продукта и построения эффективной системы обратной связи с пользователями.
Возможно, я просто не очень вдавался в детали EAV/CR, просто обратил внимание в статье на wikipedia о способе хранения информации, структуре конечных таблиц в БД.
Зачастую, перед реализацией проекта проектируется сама модель хранения: прямо на бумаге рисуется некое упрощение ER-диаграммы. Зачастую мы это делаем уже на более сложных существующих проектах, чтобы провести ревизию.
Но, боюсь, я не очень озадачивался данными теоретическими вопросами. Мы ведь занимаемся не сколько научной теоретикой, сколько средствами для практического применения. Могу лишь предположить, что наша идея, ее реализация все-таки более ближе к реляционной ее части, потому как в основу хранилища обычно у нас положена реляционная СУБД.
Зачем же так жёстко =)
1. Я хотел описать некую архитектуру, с помощью которой можно проектировать хранилища данных, и которая позволяет упрощать работу с ними.
2. Я не пытался описать работу какой-то системы с конкретными примерами, как в ней это устроено, как выглядит синтаксис запросов. Да, система есть и она работает. Возможно, в одной из будущих статей я затрону ее API.
3. Почему я должен приводить какие-то отличия? Я сказал, что система, используемая в качестве первоисточника статьи, называется Mozart. И она существует уже более 10 лет, как закрытая система разработки внутри компании. Вы можете привести примеры подобных систем, существующих более 10 лет назад? Да и вообще я не пытался сказать, какая моя система уникальная. Потому что я не знаю всех уже существующих систем, их истории. Я просто констатировал, что такая система есть.
Как описано в статье, выбирается наиболее короткий путь. Так же там написано, что вершины графа могут иметь определенный параметр, запрещающий проходить через них. Поэтому в различных случаях будет выбираться разный маршрут. Вообще, логика построения такой модели очевидна: надо избегать колец — это одно из основных правил, чтобы не возникали вопросы, аналогичные вашему.
В приведенном примере, где явно не уточняются детали, регион(человек.возраст>20) будет выбираться по кратчайшему пути, т.е. через прописку. Однако, в запрос можно вставить специальные инструкции (как описано в статье и примерно похоже на то, как описано в комментарии ниже), которые укажут функционалу делать выборку через другие связи.
1. Переабстрагировался в описании и запутал читателей. Назовем это не сервером, а службой, поэтому никакого процесса-демона нет. Цитата свыше: «Да, есть объектная БД, у нее есть внешний интерфейс для работы вспомогательных служб, они действительно через этот интерфейс могут производить CRUD, но это не касается основных приложений, который работают с репозиторием. Они-то как раз работают по вполне обычным интерфейсам языковым, поэтому проблем с транзакциями там нет, как теперь можно понять.»
3. Хотя от понятия сервер мы вроде как избавились, однако этот вопрос актуален в любом случае. Вопрос неоднозначный, поскольку существенно зависит от сложности запроса и объема данных, с которыми оперирует механизм. На практике у нас с этим нет никаких проблем. Обычно совсем другие этапы обработки вносят задержки, нежели построение связей, запросов. Безусловно, не обошлось без кэширования.
4. API системы, которая работает с репозиторием, вполне простой и затачивался всегда под то, чтобы с ним мог работать HTML-верстальщик без особых знаний программирования. Есть иные механизмы работы с репозиторием, в которых можно писать практически любые иные запросы и даже влиять на то, как работают существующий API.
5. Есть несколько способов оперировать такой логикой: на уровне репозитория через «калькулируемые» объекты, атрибуты, связи, на уровне контроллера через API, комбинирование этих методов. Есть отличные идеи, которые именно для таких случаев мы бы хотели реализовать, но нет пока возможности.
6. Вы идентифицируете человека и говорите, что с ним хотите взять Телефон и Прописка. Система сама построит связь и вытащить нужные данные в удобочитаемой форме. Возможность сказать «select related» нет, ибо связанных сущностей может быть очень много, сколько уровней взять, все деревно или один слой?.. Если, конечно, хранилище построено логично и такая связь прослеживается.
Все описанное реализовано на Java. Задумка была такая, чтобы сделать систему хранения, которая как самостоятельная единица. В нашей практике с ней работает часть сервлета, отвечающая за обработку веб-запросов (ну или сам сервелат, если более правильно). Ничто не мешает сделать любое другое приложение.
Что касается диплома, то вряд ли кому-то нужна полностью рабочая программа. Думаю, что достаточно иметь красивую концепцию и какую часть ее реализации. Там уже станет понятно, стоит ли ее развивать дальше, или это велосипед, или получается что-то сложное…
«1000 GB трафика» — сколько стоит превышение?..
Но смысл следующих действий мне уже понятен, спасибо.
А я и говорю, что пользуюсь без проблему другими сервисами.
Мне важно просто включить аккаунт и начать им пользоваться, но я не могу это сделать.
У вас будет шанс как выиграть конкурс, так и помочь общему делу развития качества проектов.
На Фликре как раз ограничение в 200 фото заставляет многих выкладывать на все подряд, а избранное. Я придерживаюсь такой позиции и пока накопил лично лишь 47 items. Да и другие друзья там тоже выкладывают именно избранное.
Планы в какой-то степени большие, но далеко загадывать бы не хотелось, потому что надо будет действовать по обстоятельствам. Я заинтересован в сообществе, которое будет как принимать участие в разработке системы, так и в ее использовании для разработки своих веб-проектов.
Напоминания по СМС мне не нужны, т.к. все события синхронизируются на HTC, который всегда со мной.
Но, боюсь, я не очень озадачивался данными теоретическими вопросами. Мы ведь занимаемся не сколько научной теоретикой, сколько средствами для практического применения. Могу лишь предположить, что наша идея, ее реализация все-таки более ближе к реляционной ее части, потому как в основу хранилища обычно у нас положена реляционная СУБД.
1. Я хотел описать некую архитектуру, с помощью которой можно проектировать хранилища данных, и которая позволяет упрощать работу с ними.
2. Я не пытался описать работу какой-то системы с конкретными примерами, как в ней это устроено, как выглядит синтаксис запросов. Да, система есть и она работает. Возможно, в одной из будущих статей я затрону ее API.
3. Почему я должен приводить какие-то отличия? Я сказал, что система, используемая в качестве первоисточника статьи, называется Mozart. И она существует уже более 10 лет, как закрытая система разработки внутри компании. Вы можете привести примеры подобных систем, существующих более 10 лет назад? Да и вообще я не пытался сказать, какая моя система уникальная. Потому что я не знаю всех уже существующих систем, их истории. Я просто констатировал, что такая система есть.
В приведенном примере, где явно не уточняются детали, регион(человек.возраст>20) будет выбираться по кратчайшему пути, т.е. через прописку. Однако, в запрос можно вставить специальные инструкции (как описано в статье и примерно похоже на то, как описано в комментарии ниже), которые укажут функционалу делать выборку через другие связи.
3. Хотя от понятия сервер мы вроде как избавились, однако этот вопрос актуален в любом случае. Вопрос неоднозначный, поскольку существенно зависит от сложности запроса и объема данных, с которыми оперирует механизм. На практике у нас с этим нет никаких проблем. Обычно совсем другие этапы обработки вносят задержки, нежели построение связей, запросов. Безусловно, не обошлось без кэширования.
4. API системы, которая работает с репозиторием, вполне простой и затачивался всегда под то, чтобы с ним мог работать HTML-верстальщик без особых знаний программирования. Есть иные механизмы работы с репозиторием, в которых можно писать практически любые иные запросы и даже влиять на то, как работают существующий API.
5. Есть несколько способов оперировать такой логикой: на уровне репозитория через «калькулируемые» объекты, атрибуты, связи, на уровне контроллера через API, комбинирование этих методов. Есть отличные идеи, которые именно для таких случаев мы бы хотели реализовать, но нет пока возможности.
6. Вы идентифицируете человека и говорите, что с ним хотите взять Телефон и Прописка. Система сама построит связь и вытащить нужные данные в удобочитаемой форме. Возможность сказать «select related» нет, ибо связанных сущностей может быть очень много, сколько уровней взять, все деревно или один слой?.. Если, конечно, хранилище построено логично и такая связь прослеживается.
Что касается диплома, то вряд ли кому-то нужна полностью рабочая программа. Думаю, что достаточно иметь красивую концепцию и какую часть ее реализации. Там уже станет понятно, стоит ли ее развивать дальше, или это велосипед, или получается что-то сложное…