Мы делаем что-то похожее на волну сейчас. И было бы очень интересно получить фидбек от пользователей GW. Открытую ссылку на тестирование я не готов давать, боюсь сервер с нашей альфа-версией уронить. Если интересно я дам вам ссылку в личном сообщении.
Это как раз наш сервис projectvolna.com там на базе google wave сделано решение по совместно работе над проектом.
В Августе мы начали разрабатывать свой сервис. Сейчас уже существует альфа-версия. Но тут ссылку давать не буду, а то сервак пока еще к серьезным нагрузкам не готовился. Кто захочет сам найдет:)
Еще в этом году планируем открыть сервис для тестирования. записаться тестером можно тут
Делаем на базе node.js и couchbase немного про архитектуру есть в конце нашей прошлой статьи на хабре.
Весь код планируем делать опенсорнсным и позже подробно про это напишем.
Да, неточно выразился. Мы выбирали из этих двух. Конечно есть и другие неблокирующие серверы. Просто конкретно с этими мы уже имели дело, знаем их в подробностях. А нода еще и позволила использовать sharejs.
Рассматривали такие альтернативы. У нас не самые простые структуры данных + права доступа, которые предполагают программную обработку прежде чем они (данные) могут быть проиндексированы или переданы пользователю. Соответсвенно готовая интеграция (или привязка?) к хранилищу для нас не бонус…
Sphinx прост в настройке, работает с очень высокой скоростью и не так требователен в ресурсах как Java решения. А еще он умеет группировать результаты поиска по аналогии с SQL, предоставляя простые агрегатные функции, что оказалось весьма полезным при практическом использовании.
Пока эту функцию не реализовали, но она в морозилке.
Точно могу сказать, что при переходе пользователей с google wave на новую платформу пользователи, не подтвердившие переход, будут удалены из базы.
Да мы сделали платформу. Одновременное редактирование текста аля Google Docs + возможность вставлять комментарии как в Google wave + OpenSocial + полнотекстовый поиск. Сейчас делаем рефакторинг и пользователей. Через 2 месяца планируем открытое тестирование.
Я думаю перед появлением интелекта обязательно должнен был появиться еще социум. И нелья рассматривать это отдельно от социума. Зарождение интелекта в человеке может произойти только от других людей. Многочисленные маугли это показали.
ИМХО нелья рассматривать «эволюцию мышления» только с нейрофизиологической точки зрения. Мне нравится рассматривать с точки зрения эволюции способов передачи информации. И между мозгом рептилии и неокортексом прошло много времени, и этого не произошло бы без ритуалав и социума.
Согласен что «патерны» плохо подходят.
Мне нравится теория, которая описывает, что базовой функцией интелекта является прогнозирование. Очень интересно об этом написано в книге «Об интеллекте». bookmate.com/ddespot/shXeGPed
Ну круто. Приятно что кому-то пригодились мои идеи.
По поводу последних предложений.
1. Интеграция модулей. Рекомендую вам прочитать книжку Фредерика Брукса «Мифический человеко-месяц». Можно до серидины только читать. Там он хорошо объясняет что бывает если интеграцию модулей оставлять на конец.
2. Неопределенность бизнес-требований. Тут я не знаю наглядный пример который поможет объяснить. Я подумаю еще. Можное привести полярные примеры.
. фундаментальное научное исследование — принципиально не известно что поучиться на выходе
. прикладное исследование, инженерное проектирование — есть общее представление, но многое станет понятно в процессе.
. Южный полюс — сборка из готового инструментария по жесткому ТЗ. Таким например бывает типовое строительство по утвержденному чертежу.
Во многих сверах современного бизнеса все больше задач по созданию систем. Такие задачм лучше требуют других рабочих и другие моделей управения этими рабочими.
Я говорю о так называемых Knowledge Workers, уже 50 лет про них говорят, но только недавно они действительно стали влиять на рынок и на модели бизнеса.
Ну вообще говоря итеративных подход не подразумевает выкатку решения конечным пользователям. Это уже на усмотрение.
В вашем случае наверно стоит делать так. Вы делаете сайт и сами его активно тестируете. Ну или если очень хочется даете его потестировать небольшой группе пользователей. Это могут быть ваши сотрудники например, когда вариант с сотрудниками не прокатывает (например потому что азартных сотрудников нет) то можно давать сайт всем пользователям, но специально тратить на продвижение лиш чуть чуть. Этим управляя кол-вом пользователей на старте.
На сколько я помню идея системы инвайтов как раз и возникла у какой-то конторы которя тестила свой сервис. И не хотела чтобы куча людей поняла что он стремный.
Тут вообще есть тысячи вариантов достижения цели. А цель простая — собрать решение целиком и посмотреть в целом как это работает и не упущены ли какие нибудь требования.
По сути итеративных помогает избежать:
1. Проблемы того что интеграция модулей проекта может оказаться неожиданно сложной
2. Проблема того что реальные бизнес требования могут сильно отличатся от прогнозируемых
Ну я бы конечно сказал что PMbook вам в руки. Но что-то честно не хочется вас туда посылать. Там столько много всего, и так оно скучно написано, что жесть.
Попробую кратко сформулировать.
Управление через проекты — модель управления организацией в котрой в качестве основной сущности выделяется проект. (определение проекта в сети есть). Такие модели управления характеризуются тем что власть проджект менеджеров сильно выше власти функциональных менеджеров. Из моей практики такое встречается в сисстемных интеграторах, строительных компаниях ну и вообще в компаниях где ведующию роль играют проекты.
Для управления через проекты не нужно знать project managmnet использовать EPM систему и сертифицироваться в PMI. Это просто есть и все.
Project Managment — набор методик(эвристик) которые кому-то помогли и поэтому их решили записать на будущее. Типо такого.
Можно еще начать рассказывать что управление через проекты не исключает управление через бизнес-процессы, но практической ценности в этом я не вижу.
Чтобы картинка выстраилась нужно просто понять как это согласуется с процесным подходом. И тут тоже вроде не сложно. Просто при инжиниринге бизнес-процессов организационные модели перекраиваются и появляется новая функциональная модель теперь уже согласовання с реальными бизнес-процессами компании
В Августе мы начали разрабатывать свой сервис. Сейчас уже существует альфа-версия. Но тут ссылку давать не буду, а то сервак пока еще к серьезным нагрузкам не готовился. Кто захочет сам найдет:)
Еще в этом году планируем открыть сервис для тестирования. записаться тестером можно тут
Делаем на базе node.js и couchbase немного про архитектуру есть в конце нашей прошлой статьи на хабре.
Весь код планируем делать опенсорнсным и позже подробно про это напишем.
Sphinx прост в настройке, работает с очень высокой скоростью и не так требователен в ресурсах как Java решения. А еще он умеет группировать результаты поиска по аналогии с SQL, предоставляя простые агрегатные функции, что оказалось весьма полезным при практическом использовании.
Точно могу сказать, что при переходе пользователей с google wave на новую платформу пользователи, не подтвердившие переход, будут удалены из базы.
Подробнее можно прочитать здесь
www.projectvolna.com/ru/doc/590006/
ИМХО нелья рассматривать «эволюцию мышления» только с нейрофизиологической точки зрения. Мне нравится рассматривать с точки зрения эволюции способов передачи информации. И между мозгом рептилии и неокортексом прошло много времени, и этого не произошло бы без ритуалав и социума.
Мне нравится теория, которая описывает, что базовой функцией интелекта является прогнозирование. Очень интересно об этом написано в книге «Об интеллекте». bookmate.com/ddespot/shXeGPed
По поводу последних предложений.
1. Интеграция модулей. Рекомендую вам прочитать книжку Фредерика Брукса «Мифический человеко-месяц». Можно до серидины только читать. Там он хорошо объясняет что бывает если интеграцию модулей оставлять на конец.
2. Неопределенность бизнес-требований. Тут я не знаю наглядный пример который поможет объяснить. Я подумаю еще. Можное привести полярные примеры.
. фундаментальное научное исследование — принципиально не известно что поучиться на выходе
. прикладное исследование, инженерное проектирование — есть общее представление, но многое станет понятно в процессе.
. Южный полюс — сборка из готового инструментария по жесткому ТЗ. Таким например бывает типовое строительство по утвержденному чертежу.
Во многих сверах современного бизнеса все больше задач по созданию систем. Такие задачм лучше требуют других рабочих и другие моделей управения этими рабочими.
Я говорю о так называемых Knowledge Workers, уже 50 лет про них говорят, но только недавно они действительно стали влиять на рынок и на модели бизнеса.
Нужно статью будет еще допиливать эту.
В вашем случае наверно стоит делать так. Вы делаете сайт и сами его активно тестируете. Ну или если очень хочется даете его потестировать небольшой группе пользователей. Это могут быть ваши сотрудники например, когда вариант с сотрудниками не прокатывает (например потому что азартных сотрудников нет) то можно давать сайт всем пользователям, но специально тратить на продвижение лиш чуть чуть. Этим управляя кол-вом пользователей на старте.
На сколько я помню идея системы инвайтов как раз и возникла у какой-то конторы которя тестила свой сервис. И не хотела чтобы куча людей поняла что он стремный.
Тут вообще есть тысячи вариантов достижения цели. А цель простая — собрать решение целиком и посмотреть в целом как это работает и не упущены ли какие нибудь требования.
По сути итеративных помогает избежать:
1. Проблемы того что интеграция модулей проекта может оказаться неожиданно сложной
2. Проблема того что реальные бизнес требования могут сильно отличатся от прогнозируемых
Попробую кратко сформулировать.
Управление через проекты — модель управления организацией в котрой в качестве основной сущности выделяется проект. (определение проекта в сети есть). Такие модели управления характеризуются тем что власть проджект менеджеров сильно выше власти функциональных менеджеров. Из моей практики такое встречается в сисстемных интеграторах, строительных компаниях ну и вообще в компаниях где ведующию роль играют проекты.
Для управления через проекты не нужно знать project managmnet использовать EPM систему и сертифицироваться в PMI. Это просто есть и все.
Project Managment — набор методик(эвристик) которые кому-то помогли и поэтому их решили записать на будущее. Типо такого.
Можно еще начать рассказывать что управление через проекты не исключает управление через бизнес-процессы, но практической ценности в этом я не вижу.
Чтобы картинка выстраилась нужно просто понять как это согласуется с процесным подходом. И тут тоже вроде не сложно. Просто при инжиниринге бизнес-процессов организационные модели перекраиваются и появляется новая функциональная модель теперь уже согласовання с реальными бизнес-процессами компании