Объяснение SVN [закрытым] непрограммистам
Вы можете использовать что-то вроде этого:
def odd_one_out(lst):
s = set(lst)
if len(s)!=2: # see comment (1)
return False
else:
return any(lst.count(x)==1 for x in s) # see comment (2)
, которое для приведенных вами примеров дает:
print(odd_one_out(list1)) # True
print(odd_one_out(list2)) # False
print(odd_one_out(list3)) # True
Чтобы объяснить код, я бы использовал первый пример список, который вы предоставили [1,1,1,1,1,1,5,1,1,1].
(1) преобразование в set удаляет все дублирующиеся значения из вашего списка, оставляя вас с {1, 5} (в произвольном порядке). Если длина этого набора отличается от 2, ваш список не соответствует вашим требованиям, поэтому возвращается False
(2) Если предположить, что set имеет длину 2, что нам нужно проверить следующее: хотя бы одно из содержащихся в нем значений появляется только один раз в оригинале list. Это то, что делает any.
10 ответов
В основном можно обсудить то, что SVN может сделать, что это не только для кода и может использоваться для любых документов в целом.
Примеры, не упоминая код будут полезны:
Автор пишет свою книгу и поместил копию ее в центральной части. Тот документ называют 1. То, когда он вносит изменение, он помещает копию его, назвало 2. Следующую копию назовут 3 и так далее. Он может всегда обращаться к предыдущим копиям, если он хочет в каком-либо моменте времени, пока у него есть доступ к тому центральному расположению.
Теперь, издательство присвоили двух корректоров его книге. С SVN корректоры могут исправить ошибки словаря и исправить их и поместить исправленную копию в центральное расположение. Писатель и корректоры могут получить последнюю копию также, и они могут считать изменения, внесенные, потому что каждый раз, когда новая копия помещается, заинтересованное лицо может записать комментарии о том, что было изменено.
Что, если корректоры находят логические и грамматические ошибки? Они не могут просто изменить его и поместить новую копию в центральное расположение, поскольку они не знают намерения писателя, и это мог возможно быть уникальный стиль записи (иначе что-то намеренно отклоняющееся от нормы). Они могут использовать программное обеспечение средства отслеживания ошибки, но это для другого сообщения.
Показ их, которые решает управление версиями задач, должен быть начальной точкой. Любой Вы могли заставить их сначала сделать .bak файлы сначала для наблюдения точки.
Но если бы они достаточно знакомы с Википедией, было бы окончательно лучше показать им историю и как Википедия защищает себя (это ответило бы на часть их любопытства), так, чтобы они видели, что это действительно полезно на практике. Вы могли установить Wiki, чтобы заставить их попробовать.
Только впоследствии вставьте их от 'скучных' текстовых команд svn...
Когда я считал его здесь существует 2 вещи. 1 обучение им понятие и 2 обучения их, как использовать SVN.
Обычно сохраняйте это простым, и сложность будет заботиться о сам вовремя и использование.
Просто, SVN является резервным копированием того, что Вы продолжаете работать, но ловко только сохраняет изменения, Вы делаете не каждую версию, которую Вы сохраняете к нему, это сохраняет его маленьким, и легко позвольте Вам сравнивать изменения со временем.
Нет никакой замены для практического опыта здесь, покажите им как контролю, обновлению и регистрации. Я предложил бы, чтобы Вы использовали Черепаху SVN, поскольку кривая обучения значительно уменьшается.
Для хранения вещей простыми, я настроил бы их собственное ответвление, на которое они могут согласиться, таким образом, они не должны понимать, что все же, и Вы просто управляете слияниями в фоновом режиме. Но скоро они приобретут навык его!
Я недавно столкнулся с этой точной проблемой, когда я представил SVN всей веб-команде разработчиков (состоящий из программистов, интерфейсных разработчиков, графических дизайнеров, редакторов контента, модераторов сайта и нетехнических менеджеров). Я навел справки о нетехнических документах, но закончил с очень мало, который был применим, таким образом, я решил создать свое собственное. К сожалению, большинство информации там ожидает, что пользователи будут знать о клиент-серверной архитектуре и что 'ответвление' - я не мог принять это в своем случае. Можно ли просмотреть одну из моей предварительной миграции PowerPoints в SlideShare ("Что Эту Вещь Называют SVN? FTW или WTF?")
http://www.slideshare.net/secret/wBsLzZb3O7cXCU
Реальный ключ должен был объяснить, что SVN - в его основе - является действительно просто лучшим способом приблизиться к копированию и вставке файлов. Избавляясь от default.bak, default2.asp, defaultBackup.asp, defaultMyCopy.asp, и т.д.... был чем-то, что все могли понять.
Поскольку мои пользователи стали более знакомыми с идеей управления исходным кодом, которое я поощрил людей задавать вопросам на нашей внутренней WIKI так, чтобы команда разработчиков (и другие пользователи) могла выручить их.
Мы также создали пользовательский настольный инструмент SVN для автоустанавливания их локального рабочего стола последовательным способом так, чтобы у всех по всей компании, как гарантировали еще, будет та же установка как everyody (c:\projects\projectname), и это также обновило их локальную установку IIS так, чтобы они могли просмотреть веб-сайты локально в любое время, не будучи должен настроить что-либо вручную.
Таким образом - обеспечивают, большое содержание руки - использует некоторый юмор - делают вещи простыми - сохраняют стандартизированным - позволяют задавать вопросы - оказывают поддержку - отождествляют с Вашими пользователями и их потребностью "продолжить их день". И, если возможно, сидите за их столом и обойдите их посредством процесса так много раз, как необходимо для получения каждого человека по препятствию.
Я нашел SVN намного легче объяснить, чем говорят, что CVS, поскольку все, кажется, папки (хотя он будет использовать мелкие копии). Просто объясните вещи этим способом им.
И не объясняйте все подробно, а скорее просто говорите им на потребности знать основание. Если Вы начинаете объяснять переходящий, и объединиться Вы можете видеть, что их голова взрывается, или возможно они будут думать, что это просто не стоит усилия для внесения небольших изменений
Как насчет древовидной метафоры, которая дала имя "соединительной линии", "переходят" и т.д.?
Скажите персоналу поддержки, что SVN является сервером исходного кода и изменяется, они делают, клиентское изменение. То, что они делают, изменить клиентскую копию исходного кода. Это должно быть отправлено на SVN, который будет сохранен там. Тот же путь, как это находится в любых других client/serer приложениях.
Я просто объяснил бы сценарий, где отслеживание предыдущих изменений важно, а также имеет ответвление для клиента.
Существуют более общие учебные руководства по управлению версиями там, которые не характерны для svn или других, которые могли бы быть полезными.
Вы не хотите сокрушать их - просто дают им главную потребность для него.
Это может быть хорошая идея сказать им, что SVN может использоваться для других вещей помимо программирования. Конфигурационные файлы, документы, что-либо в основном, что Вам нужно имеющий версию или даже просто сохраненный.
Преподавайте их репозиторию, в котором все файлы и информация о различных версиях файлов существуют, и о рабочей копии, которые являются файлами, с которыми Вы на самом деле работаете.
Запустите с простого материала как проверка файлов и фиксация. Фиксация файлов похожа на высказывание: "У меня есть новый файл или новая версия файла". Покажите им, как держать файлы в курсе с новейшими версиями.
Возможно, затем можно начать говорить им о соединительной линии, ответвлениях и тегах, слиянии и всем том джазе. Большой ресурс является непрограммистами, которые на самом деле изучили что-то. Они могут, вероятно, использовать фразы и аналогии, которые более подходят для других непрограммистов.
Я нахожу, что эта статья действительно хороша для наших новых разработчиков для взгляда на. Схемы хороши, и информация довольно проста.
Ответвление, объединяющееся с подверсией
Действительно прием заставляет их понимать важность ветвления, любой может легко схватить понятие самого управления версиями.