Пользовался этим сервисом около полутора лет назад — не понравилось, что порой сам сайт долго грузился. а так в целом система будет лучше BaseCamp.
Вообще, в последнее время пришёл к выводу, что за меньшие деньги можно арендовать собственный VPS и настроить на нём и таск-треккер, и репозиторий, и собственный сайт; да и с заказчиком солиднее общаться на «собственной» сайте, а не на стороннем сервисе;)
Кроме того, когда система управления стоит у вас — её всегда можно допилить под специфичные нужды, в отличие от готового сервиса.
Нет возможностей сортировки или фильтрации задач, перегруппировывать приходится вручную
Имхо, довольно серьёзный недостаток.
Но жизнь, как обычно, штука многогранная, и не всегда бывает удобно вписываться в холодную логику таск-трекера. Особенно это заметно на сверхсрочных проектах, когда надо сделать командный рывок и за несколько дней совершить невозможное ;)
Это вы явно преувеличиваете — всё прекрасно вписывается;)
Если поискать в интеренте, то можно найти довольно легковесные таск-треккеры; здесь же, думаю, недостатков больше, чем плюсов.
В целом, данный подход имеет право на жизнь в маленьких командах на небольших проектах, где закончил работу — удалил документ, потому что его повторно уже не используешь; в других же случаях лучше брать что-то готовое.
З.Ы.
Совет: не берите сверхсрочне проекты — и будет вам счастье=)
Сомневаюсь, что вы уложитесь в 20 строк кода, когда будете писать какой-нибудь накрученный графический фильтр на C++.
Нет, вы, конечно, можете разбить весь процесс на множество маленьких функций, данные вывести в отдельные сущности, но это только ухудшит читаемость, снизит производительность и породит множество сильно связанных объектов, что противоречит шаблону «Low Coupling».
Если компилятор умеет оптимизировать код, то, как правило, он вынесет значение в отдельную переменную. Будет она в памяти или в регистре — этот вопрос надо изучить подробнее.
Просто при таком подходе и код более осмысленным получается, и значительно легче изменить параметры цикла и оператора ветвления, что снижает количество ошибок.
Лично по мне, в конструкции «if — else » сразу видно куда идёт ветвление, и какой переменной присваивается значение; в то время, как у "?:" надо напрягать мозги при определении, что означает символ "?" и ":".
Я думаю, вы согласитесь, что текстовые обозначения намного более понятны человеку, чем различные закорючки;)
Основное уже перечислили, но хочу добавить:
1) не использую тернарный условный оператор (?:) — т.к. плохо читаем
2) во всех конструкциях if (даже, если в теле только один оператор) использую фигурные коды скобки
3) стараюсь выносить числовые значения в отдельные константы, а не бросать их в коде; т.е.
Интересная технология. В следующих обзорах было бы приятно увидеть побольше картинок, а то на словах не очень легко всё воспринять.
Есть пару вопросов:
1) Какова максимальная пропускная способность сети?
2) Как я понимаю, что бы соединиться с компьютером в Африке, нужно составить цепочку нодов от моего до конечного компьютера; учитывая, что в Wi-Fi радиус не очень большой, для этого нужно иметь довольно большую плотность распространения компьютеров. Или я что-то упустил из виду?
Видимо, там, где ASP последователям Солнечной компании нет места=/
Вообще, в последнее время пришёл к выводу, что за меньшие деньги можно арендовать собственный VPS и настроить на нём и таск-треккер, и репозиторий, и собственный сайт; да и с заказчиком солиднее общаться на «собственной» сайте, а не на стороннем сервисе;)
Кроме того, когда система управления стоит у вас — её всегда можно допилить под специфичные нужды, в отличие от готового сервиса.
www.thebigpic.org/
bitbucket.org/
www.xp-dev.com/
З.Ы.
Сейчас пишу статью по треккерам для Канбана (многие из них пригодны и для других методологий). На днях будет готова — ждите=)
scrumy.com/
unfuddle.com/
basecamphq.com/
flow.io/
Имхо, довольно серьёзный недостаток.
Это вы явно преувеличиваете — всё прекрасно вписывается;)
Если поискать в интеренте, то можно найти довольно легковесные таск-треккеры; здесь же, думаю, недостатков больше, чем плюсов.
В целом, данный подход имеет право на жизнь в маленьких командах на небольших проектах, где закончил работу — удалил документ, потому что его повторно уже не используешь; в других же случаях лучше брать что-то готовое.
З.Ы.
Совет: не берите сверхсрочне проекты — и будет вам счастье=)
Неужели?
Почти по каждому пункту могу оспорить ваше мнение, но не буду — ибо долго и будет срач=)
А Вы, вообще, долго под Linux'ом работаете?
Нет, вы, конечно, можете разбить весь процесс на множество маленьких функций, данные вывести в отдельные сущности, но это только ухудшит читаемость, снизит производительность и породит множество сильно связанных объектов, что противоречит шаблону «Low Coupling».
Просто при таком подходе и код более осмысленным получается, и значительно легче изменить параметры цикла и оператора ветвления, что снижает количество ошибок.
Я думаю, вы согласитесь, что текстовые обозначения намного более понятны человеку, чем различные закорючки;)
Ну это вы перегибаете, честное слово=)
1) не использую тернарный условный оператор (?:) — т.к. плохо читаем
2) во всех конструкциях if (даже, если в теле только один оператор) использую фигурные коды скобки
3) стараюсь выносить числовые значения в отдельные константы, а не бросать их в коде; т.е.
4) Ещё, как можно увидеть из кода, люблю после символа "//" ставить пробел=)
5) А вообще советую почитать классику (Кернигана- Пайка и Макконнелла)
Есть пару вопросов:
1) Какова максимальная пропускная способность сети?
2) Как я понимаю, что бы соединиться с компьютером в Африке, нужно составить цепочку нодов от моего до конечного компьютера; учитывая, что в Wi-Fi радиус не очень большой, для этого нужно иметь довольно большую плотность распространения компьютеров. Или я что-то упустил из виду?