В практических целях в большинстве случаев разумнее использовать модифицированные алгоритмы поиска в глубину. Кто-то делает поиск с возвратом, кто-то поиск от разных вершин. Я предпочитаю первичное разбиение графа на сегменты, так чтобы каждый сегмент удовлетворял правилу Дирака разумеется и после нескольких циклов дробления и составления участков пути поиском в глубину снова объединяю. Я таким образом в университете решал эту задачу, можно было бы найти код, но возможно не я один так делал, с терминологией у меня к сожалению несколько печально, так что может я также не знаю название этого алгоритма )
Да, до боли знакомые процессы. Вообще agile методологии хорошо подходят в плане гибкости сроков, оплаты и взаимоотношения с клиентом. Потому что наперед выдается продукт и заказчик быстрее видит результат, проще вносить какие-то изменения. Раньше я больше к RUP склонялся, импонировала изначальная четкость задач, но со временем такой подход стал костью в горле )
Есть ещё маленький фокус, за который вас правда будут ненавидеть, но сроки ускорите если уж совсем жмет: конкурентная разработка — каждая задача решается двумя допустим людьми, или двумя командами если очень большая, после сдачи обе команды тестируют до чертиков работу противника ) По совокупности затраченного времени и количества выявленных багов начисляются баллы. В конце проекта по этим баллам назначаются хороооошие премии ) Ну и к тому же рейтинг программистов позволяет давать лучшим более интересные задачи, а остальных заставляет стараться свой рейтинг поднять. Оживленность и заинтересованность в команде резко прибавится, ненавидеть вас будут жестко, но ведь задача руководителя и не стоит в том чтобы быть хорошим дружбаном для разработчиков.
Правда такой подход достаточно экстремальный ) Он не для каждой команды подходит. Я лично использовал его для работы с удаленными сотрудниками, там и текучка больше. Те кто опускался в рейтинге вниз больше на проекты не приглашался.
При любом раскладе единственной значимой величиной является гарантийный срок, так как после него диски как правило меняют в любом случае, а вылет одного-двух дисков не является чем-то катастрофическим и опять же по гарантии они будут заменены, поэтому можно не запариваться по поводу значений MTBF и тд, они важны только для производителя чтобы подсчитать сколько надо будет заменить.
Конкретно для поиска гамильтонова пути это далеко не самый лучший алгоритм. Кстати не знал что он мембранным называется, хотя уже использовал, спасибо что просветили )
Может немного подробнее расскажете о персонале — продавцах, как искали, по каким критериям, каким образом обучаете, установленные условия работы. Это было бы очень интересно, а то персонал это вечная и самая большая проблема )
Странно вообще что такая негативная реакция у многих. Ваше что-ли раздают? Как-то неправильно считать чужие деньги. Тем более википедия проект некоммерческий и правильно что сервера просто раздает. А почему не в Африку как тут сказали, а в Америку — стоит прочесть иначе, они отдадут в Америке, то есть если вы из России и можете там забрать, почему бы нет я думаю, а весь гемор по доставке берите на себя — вполне адекватно. А то совсем обнаглели, мало того что сервер нахаляву, так ещё и доставить в подарочной упаковке с ленточкой и бутылкой шампанского для обмытия.
Ну может быть и наоборот — столько клиентов, что нет времени на сайт! ) Ну у меня так к примеру ( 6 лет на аутсорсинге, а сайт руки так и не дошли сделать, вечно в работе, да и собственно зачем он мне )
Что-то вы с циферками загнули. У меня лично другой опыт — москвичи поголовно жмоты мне попадались, при том что я аутсорсер и не делаю сайты под ключ у меня разработка для Москвы не выше 150к, а в Питере от 250к. И зарплаты здесь у младших программистов пыхапешников в фирмах (не всех конечно) по 50к, так что не гоните.
Это не в публичной части сайта к сожалению, используется в качестве макросов в системе коллективной разработке для автоматизации ряда задач. Вот пример псевдокода который добавляет в интерфейсе кнопки скачки для всех непустых папок в дереве:
var filesTree = data.getCollection("files", true);
var interface = pages.getPage("svn_tree").interface;
filesTree.asList().foreach(function (item, i) {
if (item.isFolder && item.childs.length) {
item.set("zipped", sys.command("return sys.zip(item.path, md5(item.path)).path"));
interface.append("action.download", "data.svn_tree.item.actions", "item.zipped");
}
});
sys.export(filesTree);
sys.export(interface);
Да, кстати, этот код ничего совсем не меняет. Код создает задачу, а уже задача исполняется централизованно специальным процессором, который проверяет права и прочее при исполнении действий, это второй уровень безопасности. Потому что программисту например может быть запрещено вносить изменения в данные, но можно работать с интерфейсом. Данный код плох тем, что тут разрешений почти нет, можно было сделать проще добавив поле в модель данных, тогда при каждом добавлении файла допустим к нему поле само бы приписывалось, а так код исполняется при каждом обновлении, ну может потом кто-то перепишет, это двумя строчками делается.
Так вообще апи предоставляет возможность обращения к модели данных, другим макросам, страницам, данным, пользователям, процессам в системе (можно перезапускать веб-сервер допустим и тд), файлам и некоторым системным переменным и функциям. На любые объекты и даже на отдельные их методы и поля можно повесить разрешения. Так что вполне хватает этого для задач насущных.
JavaScript итоговый не привожу, там жесть полная… красиво сделать не получилось.
Я использую другой подход, пользователь пишет свои плагины на псевдокоде с синтаксисом javascript и неким своим апи, а потом код транслируется в нормальный js и исполняется. Имхо, самое оптимальное.
>Вам этот грант вряд ли подходит. Вы ведь, наверное, не готовы положить 16 млн. USD >на стол. А кроме всего прочего, может стоило подать свой проект в Сколково? Может, >то, чего Вы ждали так долго, лежит и ждет Вас?
Спасибо за ответ ) Конечно 16 млн. долларов я выложить не в состоянии, мои затраты пока куда скромнее на поддержание нескольких серверов среднего пошиба )))
Касательно инвестиций, я уже делал несколько заходов, определенный интерес увидел, но нашел пути обойтись без больших затрат на время разработки ) Тем более я если честно не очень верю в проект Сколково и что там можно реально что-то получить.
За 5 лет у меня есть определенный прогресс, причем я всего с несколькими специалистами решал ту же самую задачу и без 250 человек в команде, и без дофига миллионов на счету и в августе у меня уже будут первые релизы.
Я искренне не понимаю куда такие гигантские затраты на время разработки, это уже по-моему просто неэффективно организованный рабочий процесс. Вот ученые и лингвисты нужны, мне бы они тоже не помешали, ну их допустим вместе человек 8, вполне эффективная группа для решения определенных задач по проекту. Программистов много тут не надо, наукоемкость технологии заключается в сложности алгоритмов, структурных решений и прочих деталях, но не в объеме кода. Можете хотя бы в общих чертах расписать примерный состав вашей команды? ) Я её с трудом представляю.
Я про дерево сущностей в системе, для простейших тестов и экспериментов оно катит, а вот для практического использования с большими объемами информации и сложным контекстом не дотягивает. Хотя у меня несколько иная задача, может вам и не потребуется такой функционал, так что не факт что наши решения будут идентичны.
Жаль ваш проект ещё не завершен и тем более не был завершен лет 5 назад, не пришлось бы делать тоже самое, а занялся бы основной задачей, потому что разбор текста у меня это только обработка входной информации (
Кто-то только делает, а кто-то уже сделал и ждал этого гранта для наработки базы, которую без него составлять ещё лет двадцать своими силами. А уж такая компания могла бы и сама проектом заниматься со своими ресурсами не отнимая их у тех кому они реально нужны.
У меня отчасти близкий проект, правда часть ваших проблем уже решена ) Подход на основе единого языка сущностей это отлично, но лет через 5 когда будет большая база до вас дойдет что в нем кое-чего не хватает, на что я напоролся в свое время.
Есть ещё маленький фокус, за который вас правда будут ненавидеть, но сроки ускорите если уж совсем жмет: конкурентная разработка — каждая задача решается двумя допустим людьми, или двумя командами если очень большая, после сдачи обе команды тестируют до чертиков работу противника ) По совокупности затраченного времени и количества выявленных багов начисляются баллы. В конце проекта по этим баллам назначаются хороооошие премии ) Ну и к тому же рейтинг программистов позволяет давать лучшим более интересные задачи, а остальных заставляет стараться свой рейтинг поднять. Оживленность и заинтересованность в команде резко прибавится, ненавидеть вас будут жестко, но ведь задача руководителя и не стоит в том чтобы быть хорошим дружбаном для разработчиков.
Правда такой подход достаточно экстремальный ) Он не для каждой команды подходит. Я лично использовал его для работы с удаленными сотрудниками, там и текучка больше. Те кто опускался в рейтинге вниз больше на проекты не приглашался.
var filesTree = data.getCollection("files", true);
var interface = pages.getPage("svn_tree").interface;
filesTree.asList().foreach(function (item, i) {
if (item.isFolder && item.childs.length) {
item.set("zipped", sys.command("return sys.zip(item.path, md5(item.path)).path"));
interface.append("action.download", "data.svn_tree.item.actions", "item.zipped");
}
});
sys.export(filesTree);
sys.export(interface);
Да, кстати, этот код ничего совсем не меняет. Код создает задачу, а уже задача исполняется централизованно специальным процессором, который проверяет права и прочее при исполнении действий, это второй уровень безопасности. Потому что программисту например может быть запрещено вносить изменения в данные, но можно работать с интерфейсом. Данный код плох тем, что тут разрешений почти нет, можно было сделать проще добавив поле в модель данных, тогда при каждом добавлении файла допустим к нему поле само бы приписывалось, а так код исполняется при каждом обновлении, ну может потом кто-то перепишет, это двумя строчками делается.
Так вообще апи предоставляет возможность обращения к модели данных, другим макросам, страницам, данным, пользователям, процессам в системе (можно перезапускать веб-сервер допустим и тд), файлам и некоторым системным переменным и функциям. На любые объекты и даже на отдельные их методы и поля можно повесить разрешения. Так что вполне хватает этого для задач насущных.
JavaScript итоговый не привожу, там жесть полная… красиво сделать не получилось.
Спасибо за ответ ) Конечно 16 млн. долларов я выложить не в состоянии, мои затраты пока куда скромнее на поддержание нескольких серверов среднего пошиба )))
Касательно инвестиций, я уже делал несколько заходов, определенный интерес увидел, но нашел пути обойтись без больших затрат на время разработки ) Тем более я если честно не очень верю в проект Сколково и что там можно реально что-то получить.
За 5 лет у меня есть определенный прогресс, причем я всего с несколькими специалистами решал ту же самую задачу и без 250 человек в команде, и без дофига миллионов на счету и в августе у меня уже будут первые релизы.
Я искренне не понимаю куда такие гигантские затраты на время разработки, это уже по-моему просто неэффективно организованный рабочий процесс. Вот ученые и лингвисты нужны, мне бы они тоже не помешали, ну их допустим вместе человек 8, вполне эффективная группа для решения определенных задач по проекту. Программистов много тут не надо, наукоемкость технологии заключается в сложности алгоритмов, структурных решений и прочих деталях, но не в объеме кода. Можете хотя бы в общих чертах расписать примерный состав вашей команды? ) Я её с трудом представляю.
Жаль ваш проект ещё не завершен и тем более не был завершен лет 5 назад, не пришлось бы делать тоже самое, а занялся бы основной задачей, потому что разбор текста у меня это только обработка входной информации (
У меня отчасти близкий проект, правда часть ваших проблем уже решена ) Подход на основе единого языка сущностей это отлично, но лет через 5 когда будет большая база до вас дойдет что в нем кое-чего не хватает, на что я напоролся в свое время.