В чем проблема раз в 5-10 минут проверять, есть ли слова на повторение — и зажигать это окошко? Я просто не в курсе, насколько это сложно в Анки настроить, но по идее методики, которую они исповедуют, это должно быть одним из стандартных подходов к использованию программы.
К сожалению не могу аргументированно заступиться за Анки, т.к. сам использую AnyMemo на андроиде — но суть у них похожая: так или иначе где-то они отражают, сколько слов стоит повторить «прямо сейчас», чтобы их не забыть. Думаю, Анки и на десктопе как-то должно быть можно настроить на то, чтобы при достижении некоторого числа «потенциально забытых» слов, он просил их повторить…
Насколько я понял, письмо писалось долго, не за один присест. Возможно, в то время, когда оно создавалось, Твиттер был не лучшим примером. Плюс автор работал в Амазоне и знаком с их внутренней кухней — потому он и взял пример, который был ему ближе.
Извините, но я все равно Вас не понимаю. Вы говорите, что централизация заставит сотрудников заливать код раз в день и чаще на центральный сервер? Нет, не заставит. Всегда найдутся люди, которые копят ченжи и выкладывают по завершении таска — это вопрос баланса между комфортом программиста и требованиями решаемой задачи. Если Вам нужны итеративные улучшения, если есть возможность этот итеративный прогресс подтверждать тестами, то просто попросите человека выкладывать почаще — и не важно, какая при этом у вас используется система, это не вопрос техпроцесса совершенно.
А заодно с ними и менеджера, который считает наличие коммитов, содержимое которых он все равно не в состоянии понять, признаком прогресса по поставленной задаче :)
Именно, потому смена системы контроля версий, ровно как и любой другой части техпроцесса — вопрос сложный и индивидуальный, зависящий по большей части от других компонент того же техпроцесса, а вовсе не от идеологических или технических подробностей новой системы самой по себе.
Я знаю фирмы, где используется не Svn, где Svn комбинируется с другими системами (Git или Mercurial). Но оглянитесь: некоторые фирмы до сих пор используют CC, VSS и CVS. Крупные IT-фирмы на то и крупные, чтобы плестись в хвосте эволюции — у них стоимость внедрения новых решений куда выше, чем у средних и мелких — а ресурсы точно так же выжимаются по максимуму, и найти силы на общий переход, да еще и со спорными преимуществами, бывает просто невозможно.
Я ни в коей мере не пытаюсь в этом споре доказать, что Svn хуже (ниже я написал немало комментариев как в его защиту, так и против него), но ожидать, что мерилом его устарелости будут ведущие игроки рынка точно не приходится — им просто не интересно и не выгодно проверять на себе новые решения.
Результатом работы программиста является не ченж-лист, а закрытый таск — тот факт, что промежуточные коммиты хранятся на их машинах, а не на центральном сервере, не является проблемой, т.к. это всего лишь кусочек выполнения таска, который в таком виде никому не нужен.
Кто и что сделал так же оценивается по закрытым таскам, а не по числу коммитов. Да и что это за метрика такая: человек, который на таск делает 100 коммитов продуктивнее, чем тот, кто делает один?
Т.к. таски при нормальном режиме работы редко длятся больше двух дней, а на рабочих машинах у многих стоит рейд, то потеря данных в результате смерти машины — достаточно минорный риск: не больший по затратам времени и сил, чем, собственно, замена рабочей машины.
При наличии центрального репо ветки так же поддаются контролю.
Неудобство запрета доступа на конкретные части проекта — да, это недостаток вышеупомянутых систем, но к размазанности он относится слабо по-моему.
Ну и наконец, нет, Вы не можете уволить кого-угодно в любой момент, на это нужен месяц, а за это время можно без проблем залить недостающие изменения куда-либо.
К сожалению не всегда это возможно. Переименование класса — типичный пример: меняется одновременно и содержимое, и имя файла. Изменить только одно нельзя — та же Java просто откажется такой файл компилировать.
Вы две разных операции в одну кучу смешали. Если я переименовал 100500 файлов, то в Гит-е мне закоммитить — одна команда, а в Свн-е — надо ломать голову, как объяснить системе контроля версий, что случилось. Это сильно разные вещи.
В гуях Меркуриала для этого спец. интерфейс есть с автопоиском переименований кстати.
Это вопрос тулсета и культуры, безусловно. Но та же IDEA при переименовании делает все верно, как и студия с правильными плагинами. Еще наверняка можно это коммит-хуком подпереть, который будет проверять, что очень похожий файл был удален и добавлен одновременно в одном ченж-листе. Понятно, что всей проблемы это не решит, но культура — штука сложная в любом случае. Тот же меркуриал тоже не любит, когда ему не подсказывают, что переименовали или скопировали. Только Гит умеет автоматом детектировать такие операции, но и он делает это не идеально, если содержимое файла при переименовании изменилось.
Я ни в коей мере не пытаюсь в этом споре доказать, что Svn хуже (ниже я написал немало комментариев как в его защиту, так и против него), но ожидать, что мерилом его устарелости будут ведущие игроки рынка точно не приходится — им просто не интересно и не выгодно проверять на себе новые решения.
Результатом работы программиста является не ченж-лист, а закрытый таск — тот факт, что промежуточные коммиты хранятся на их машинах, а не на центральном сервере, не является проблемой, т.к. это всего лишь кусочек выполнения таска, который в таком виде никому не нужен.
Кто и что сделал так же оценивается по закрытым таскам, а не по числу коммитов. Да и что это за метрика такая: человек, который на таск делает 100 коммитов продуктивнее, чем тот, кто делает один?
Т.к. таски при нормальном режиме работы редко длятся больше двух дней, а на рабочих машинах у многих стоит рейд, то потеря данных в результате смерти машины — достаточно минорный риск: не больший по затратам времени и сил, чем, собственно, замена рабочей машины.
При наличии центрального репо ветки так же поддаются контролю.
Неудобство запрета доступа на конкретные части проекта — да, это недостаток вышеупомянутых систем, но к размазанности он относится слабо по-моему.
Ну и наконец, нет, Вы не можете уволить кого-угодно в любой момент, на это нужен месяц, а за это время можно без проблем залить недостающие изменения куда-либо.
В гуях Меркуриала для этого спец. интерфейс есть с автопоиском переименований кстати.