На мой взгляд, наука доказала, что в чате можно имитировать довольно удачно человека. Искусственный собеседник не сильно ограничен в средствах построения диалога и имеет мощную базу ответов — "«Сьюзетта» начала проявлять признаки раздражения, потом рассердилась, а затем ей стало скучно и она пригрозила судье прервать беседу". Попробуй, отличи такого :)
Нужно ставить следующий рубеж для ИИ.
Работать ученым или программистом — вот что требуется от ИИ. От этой точки можно уже будет почувствовать дыхание эпохи Технологической Сингулярности.
>Вики вообще создавалась и заточена на совместное редактирование документов
В данном случае Вика лежит в Личном разделе, т.е. это моя собственная Вика :), которой пользуюсь только я и она доступна мне по двум кликам. Так что здесь нет никаких проблем с накладностью.
Сущности в моем Личном разделе я конфигурирую по своим надобностям, задачи, вики и т.д.
Аргументация такая — это быстрый сброс «сырой» мысли, wiki для этого вполне подходит, типа как в блокнот черкнуть. Потом на основе этого составляются задачи с точной формулировкой.
Но Вы правы, можно сделать еще лучше. Все будет — можете предложите имя для функции?
Мы делаем и пользуемся, само собой. Задач я вижу 2. Цену не считать же задачей :)
Насчет «хотя бы свободной сортировки задач» не понял — что имеется ввиду. Фильтры можно настроить, само собой, в том числе и во Входящих.
Насчет «Интересная цитата». Мысль очень здравая, меня самого часто посещает. Сейчас как я лично поступаю. У меня в закладках wiki документ, на который я перехожу и добавляю строку. Можно создать папку Задачи, поместить в закладки, тогда через два клика появится окно для ввода имени новой задачи.
>Но мы все должны быть зарегистрированы в одной и той же системе, так как между Basecamp никак не умеет общаться, скажем, с Мегапланом или Teamer-ом. Думаю, что этого не умеет ни одна система. Разве
что, допиленные специально для этого дорогие инструменты типа Джиры.
Это сложный функционал, со всеми обмениваться. Хотя со временем будет что-нибудь a-la Google Reader только для задач.
>Единственная фиксированная вещь, которая должна быть — папка (или что-то этого вида) с названием «Входящие», куда попадают все непросмотренные мной задачи.
Остальное дело вкуса. Можно так развить, а можно как-то иначе.
>Очень мало свободных и бесплатных систем.
Ну если redmine не устраивает, и пользователей больше 5-10 ( сейчас многие системы бесплатны на таком количестве пользователей), то, конечно, маловато.
Где-то с тысячи клиентов раз в две недели приходится чинить «битую» базу — «Internal gds software consistency check». Нужно заметить, что используется Firebird-1.5.5.4926, может, уже улучшили ситуацию. А может, и вообще это не с Firebird связано. Но вот такая ситуация имеет место быть.
> Итог: разглагольствовать можно сутками. ПРОБУЙТЕ!!!
Дык я ПРОБУЮ :). У меня коллега два дня уже убил на конвертацию базы svn->git, не конвертируется пока.
Ожидая результата мы решили поработать в SVN таким способом. Пробы удачны, ветки делаются а потом сливаются без особых проблем ( ясно, что это потому, что изменения простые). Но стало непонятно, а зачем так делать?
>Так проще потом отслеживать фиксы и фичи.
Про это нельзя ли подробнее, что это значит «отслеживать». Я «отслеживаю» в трекере, мне по сути все равно, какие там коммиты в репозитории. Главный критерий — все работает и тесты проходят.
>В итоге я знаю, что если что-то в доставках поломалось — в какой ветке искать изменения приведшие к поломкам.
Это вроде не конкретный пример, а лишь теоретическое соображение.
У меня задача в трекере связана с commitа-ми, если надо, я могу получить список коммитов, связанных с задачей. Но это пока не разу не требовалось, а мы выпустил почти сотню релизов только одного продукта. Что мы делаем не так?
Вот смысл делать ветку на каждую фичу мне не очень понятен.
>можно работать над несколькими фичами и фиксами одновременно
Да, иногда (редко) приходится все бросать и заниматься другой задачей. Тут да — делается ветка, туда сохраняется текущая работа и происходит переключение между задачами. В этом случае действительно, изредка делаются ветки.
Но зачем их каждый раз-то принудительно делать?
>Таким образом можно легко отслеживать добавленные фичи
Что конкретно имеется ввиду под «отслеживанием»? Интересно было бы рассмотреть конкретный пример из практики.
Вот у меня сейчас в сборке полторы сотни задач, они все лежат в трекере, я их там отслеживаю, из них четыре десятка я сгенерировал в процессе ручного тестирования новой сборки, типа тут подправить, там улучшить и т.д.
Допустим, у меня будет полторы сотни веток, что мне это даст, кроме головной боли по интегрированию их в «главную»?
Коллега, а не поделитесь ли конкретными примерами, где используется частое легкое ветвление и слияние?
Рассмотрим типичные сценарии в одном из моих проектов. Характериcтики проекта — шесть разработчиков, SVN, Scrum, Test Driven Development.
В trunk у меня сейчас B84 ( следующая версия), B83 — в branches ( текущая версия, предрелизное состояние), B82, B81 — в tags.
Сценарий 1) Новая задача для B84. Разработка, unit-тесты проходят — commit в trunk. И так НЕСКОЛЬКО раз. Тесты и функциональность наращиваются постепенно, однако в любой момент времени тесты проходят.
Сценарий 2) Фикс для B83. Разработка, unit-тесты проходят — commit в branches\B83 + merge с trunk
Сценарий 3) Фикс для B82. Ветка в branches\B82.2, Разработка, unit-тесты проходят — commit в branches\B82.2 + merge с trunk и branches\B83
Сценарий типа (3) редок, и в 99% запускается только серьезных дефектов — мы выпускаем версию раз в 1-2 месяца, так что клиент в большинстве случаев может дождаться следующей версии (а раньше выпускали версию вообще раз в две недели, отсюда такие номерки).
Я тут пока не вижу необходимости использовать частое ветвление. Т.е. ветки делаются, но обычно по количеству релизов.
Если статья не сравнивает, тогда аргументация «Почему git» в терминах «основные плюсы» наверное не очень правильна. Плюсы — они же относительные.
Да вот и автор пишет сам: «Отличается от SVN отсутствием необходимости в центральном репозитории (который все же хорошо было бы держать)». Т.е. как бы плюс, но не особо и нужный, ибо все равно центральный репозиторий нужен.
Теперь по пунктам
1. Как же на завязан, если сливать в центральный репозиторий все равно придется.
2. Вот это-то и не раскрыто совершенно на примерах. Типа вот в svn такая-то операция делается вот так, а в git — по другому, видите, гораздо лучше, особенно слияние. Пока не вижу. Про кучу локальных веток я понял.
3. Что мешает переключиться на другую ветку-то?
4. Это не могу оценить, ни разу не требовалось
Все равно получается, что текста вроде как много, но «почему git» предлагается узнать на собственном опыте.
Нужно ставить следующий рубеж для ИИ.
Работать ученым или программистом — вот что требуется от ИИ. От этой точки можно уже будет почувствовать дыхание эпохи Технологической Сингулярности.
Там у нас rich edit поверх вики, в основном в нем редактируется все. Редко, когда приходится в синтаксис смотреть.
>Согласитесь, стикер на мониторе или его аналог на десктопе часто куда оперативнее и проще?
Именно — стикер на мониторе. Нет средства быстрее и оперативнее.
В данном случае Вика лежит в Личном разделе, т.е. это моя собственная Вика :), которой пользуюсь только я и она доступна мне по двум кликам. Так что здесь нет никаких проблем с накладностью.
Сущности в моем Личном разделе я конфигурирую по своим надобностям, задачи, вики и т.д.
silverlight× 8556
Но Вы правы, можно сделать еще лучше. Все будет — можете предложите имя для функции?
Насчет «хотя бы свободной сортировки задач» не понял — что имеется ввиду. Фильтры можно настроить, само собой, в том числе и во Входящих.
Насчет «Интересная цитата». Мысль очень здравая, меня самого часто посещает. Сейчас как я лично поступаю. У меня в закладках wiki документ, на который я перехожу и добавляю строку. Можно создать папку Задачи, поместить в закладки, тогда через два клика появится окно для ввода имени новой задачи.
Можно сделать и еще лучше.
Предложите для функции короткое и емкое название, как могло бы быть озвучено в Руководстве пользователя. Сделаем в следующей версии. Утром в газете вечером в куплете ©
stackoverflow.com/tags
c#× 116712
java× 73195
php× 64282
javascript× 55779
.net× 55517
asp.net× 51470
jquery× 46702
c++× 44925
что, допиленные специально для этого дорогие инструменты типа Джиры.
Это сложный функционал, со всеми обмениваться. Хотя со временем будет что-нибудь a-la Google Reader только для задач.
>Единственная фиксированная вещь, которая должна быть — папка (или что-то этого вида) с названием «Входящие», куда попадают все непросмотренные мной задачи.
Эх, у нас две папки, Входящие и Исходящие
Остальное дело вкуса. Можно так развить, а можно как-то иначе.
>Очень мало свободных и бесплатных систем.
Ну если redmine не устраивает, и пользователей больше 5-10 ( сейчас многие системы бесплатны на таком количестве пользователей), то, конечно, маловато.
Ну 1.5.5 это 2009-10-08.
Напишу в личку, thx
Дык я ПРОБУЮ :). У меня коллега два дня уже убил на конвертацию базы svn->git, не конвертируется пока.
Ожидая результата мы решили поработать в SVN таким способом. Пробы удачны, ветки делаются а потом сливаются без особых проблем ( ясно, что это потому, что изменения простые). Но стало непонятно, а зачем так делать?
>Так проще потом отслеживать фиксы и фичи.
Про это нельзя ли подробнее, что это значит «отслеживать». Я «отслеживаю» в трекере, мне по сути все равно, какие там коммиты в репозитории. Главный критерий — все работает и тесты проходят.
>В итоге я знаю, что если что-то в доставках поломалось — в какой ветке искать изменения приведшие к поломкам.
Это вроде не конкретный пример, а лишь теоретическое соображение.
У меня задача в трекере связана с commitа-ми, если надо, я могу получить список коммитов, связанных с задачей. Но это пока не разу не требовалось, а мы выпустил почти сотню релизов только одного продукта. Что мы делаем не так?
>можно работать над несколькими фичами и фиксами одновременно
Да, иногда (редко) приходится все бросать и заниматься другой задачей. Тут да — делается ветка, туда сохраняется текущая работа и происходит переключение между задачами. В этом случае действительно, изредка делаются ветки.
Но зачем их каждый раз-то принудительно делать?
>Таким образом можно легко отслеживать добавленные фичи
Что конкретно имеется ввиду под «отслеживанием»? Интересно было бы рассмотреть конкретный пример из практики.
Вот у меня сейчас в сборке полторы сотни задач, они все лежат в трекере, я их там отслеживаю, из них четыре десятка я сгенерировал в процессе ручного тестирования новой сборки, типа тут подправить, там улучшить и т.д.
Допустим, у меня будет полторы сотни веток, что мне это даст, кроме головной боли по интегрированию их в «главную»?
Рассмотрим типичные сценарии в одном из моих проектов. Характериcтики проекта — шесть разработчиков, SVN, Scrum, Test Driven Development.
В trunk у меня сейчас B84 ( следующая версия), B83 — в branches ( текущая версия, предрелизное состояние), B82, B81 — в tags.
Сценарий 1) Новая задача для B84. Разработка, unit-тесты проходят — commit в trunk. И так НЕСКОЛЬКО раз. Тесты и функциональность наращиваются постепенно, однако в любой момент времени тесты проходят.
Сценарий 2) Фикс для B83. Разработка, unit-тесты проходят — commit в branches\B83 + merge с trunk
Сценарий 3) Фикс для B82. Ветка в branches\B82.2, Разработка, unit-тесты проходят — commit в branches\B82.2 + merge с trunk и branches\B83
Сценарий типа (3) редок, и в 99% запускается только серьезных дефектов — мы выпускаем версию раз в 1-2 месяца, так что клиент в большинстве случаев может дождаться следующей версии (а раньше выпускали версию вообще раз в две недели, отсюда такие номерки).
Я тут пока не вижу необходимости использовать частое ветвление. Т.е. ветки делаются, но обычно по количеству релизов.
Не поделитесь конкретными примерами? Типа вот такой сценарий, в svn все было бы плохо, а в git — все хорошо.
Да вот и автор пишет сам: «Отличается от SVN отсутствием необходимости в центральном репозитории (который все же хорошо было бы держать)». Т.е. как бы плюс, но не особо и нужный, ибо все равно центральный репозиторий нужен.
Теперь по пунктам
1. Как же на завязан, если сливать в центральный репозиторий все равно придется.
2. Вот это-то и не раскрыто совершенно на примерах. Типа вот в svn такая-то операция делается вот так, а в git — по другому, видите, гораздо лучше, особенно слияние. Пока не вижу. Про кучу локальных веток я понял.
3. Что мешает переключиться на другую ветку-то?
4. Это не могу оценить, ни разу не требовалось
Все равно получается, что текста вроде как много, но «почему git» предлагается узнать на собственном опыте.