Какие инструменты Вы используете, чтобы поделиться информацией среди разработчиков в Вашей группе?
Вот как вы можете сделать это с Javascript без jQuery:
var checkboxData = [];
var trs = document.querySelectorAll("#yourtable tr");
for (var tr of trs) {
var rowCheckboxes = tr.querySelectorAll("input[type=checkbox]");
checkboxData.push([]);
for (checkbox of rowCheckboxes) {
checkboxData[checkboxData.length - 1].push(checkbox.checked ? "checked" : "unchecked");
}
};
С jQuery вы делаете нечто подобное, но с $("#yourtable tr").each и .find().
15 ответов
Ну, безотносительно технологии или продукта, который Вы решите использовать, они не будут проблемой. Всем знаниям, которыми не достаточно хорошо делятся в кофеварке, необходимо уделять внимание.
- Внимание, на самом деле пишущий это (быть этим документ о сетевом диске, странице Wiki, сервере SharePoint, безотносительно).
- Внимание для категоризации его (путем соединения, теги, веб-страницы, безотносительно...).
- Внимание, чтобы усовершенствовать его (отдельным или запланированным усилием по запросу).
Независимо от того, что Вы используете, никакая технология не поможет с этим. Для этого необходимо заставить команду записывать вещи, читать вещи в репозитории сначала прежде, чем позвонить (и прервать) набор других членов команды, и исправлять вещи, если они неправы.
На основе моего опыта SharePoint и Wikis работают о том же. Необходимо победить людей для использования его, пока они не испытывают это, они хотят использовать его, потому что они в какой-то момент испытают тот такой тип совместного пользования информацией, может сэкономить время - их время.
Поскольку у Вас уже есть привычка к тому, чтобы делиться информацией, это не может быть большой частью тяжелой проблемы для Вас. Я рекомендовал бы, чтобы один (или некоторые, лучше меньше, чем слишком многие) обеспечили некоторую (запасную) начальную структуру и затем позволили временной замене начаться. Поскольку никакая идеальная классификация не существует, Вы не должны волноваться слишком много об этом.
Wikis работали хорошо на меня в прошлом. Мы использовали свободный ScrewTurn wiki, работающий на маленьком VM. Это было быстро, очень просто в использовании, и людям, казалось, нравился он так, они на самом деле использовали его.
Skype хорош для совместного использования информации/спрашивать быстрые вопросы. Для некоторого долгосрочного ноу-хау мы используем Wiki.
Поскольку программист, который работает из дома (без любой опции похода "в офис") - Наши основные средства сообщения, является частным каналом IRC. Мы - малочисленная команда 3 разработчиков, таким образом, она работает хорошо.
Наша команда не является очень многочисленной (11 разработчиков), таким образом, у нас есть каждый месяц встреча, на которой мы делимся знаниями. Около этого я занят, добавляя интересные документы интранет.
И мы часто идем друг другу для задавания вопросов.
Мы используем Походный костер для нашего чата и Jing для нашего изображения и/или коротких видеодемонстраций. Они оказались неоценимыми.
Мы используем Fogbugz для wikis, дискуссионных групп и сфокусированного обсуждения особых случаев. Для мгновенного обмена сообщениями мы используем Sametime. Эта комбинация оказалась очень мощной для нас, потому что она обеспечивает груды функциональности, не вызывая много интерфейса на нас. Низкая церемония хороша.
ОТМЕТЬТЕ - мгновенный обмен сообщениями является единственным аспектом Sametime, который мы используем - я предполагаю, что существует много других сумасшедших вещей, которые можно сделать, и мы абсолютно не заинтересованы.
Одно место я работал мы также, использовало Wiki, но нашло, что не обновлялось достаточно часто. Должен был продолжать продвигать людей использовать его.
Очевидно, мы сумасшедшая совместно используемая файловая система с соответствием общим почтовым папкам для проекта comms.
Мы также использовали внутреннюю систему Мгновенного обмена сообщениями для предотвращения общих электронных писем вокруг офиса, но как Ручей Вуали я, вероятно, теперь реализую частный клон Твиттера.
Одна вещь, которую мы сделали, имеют день каждый год, где все разработчики встретились бы где-нибудь возле офиса и представили бы друг другу на интересных вещах, они находили/делали. Иногда наполняйте из проектов, иногда от персональной работы и иногда со дня месяц, людям разрешили работать надо что любивший (как 20%-е время Google).
Мы используем Yammer для короткого infos, который является подобным Твиттеру сервисом, но это является частным в Вашем почтовом домене. Существует веб-приложение, Windows и клиент Mac и даже версия iPhone.
Для документации мы используем Wiki с открытым исходным кодом (ScrewturnWiki на платформе ASP.NET). Это было принято очень хорошо.
Мы используем комбинацию Trac для Wiki, scm, и покупку билетов и частный сервер Бессмысленных данных/IRC для нас, чтобы говорить друг с другом.
В моем предыдущем задании мы использовали SharePoint для хранения нашей документации организованной. Это было довольно успешно, но существует, очевидно, потребность усовершенствовать сайт, релевантный и соответственно установить. Однако архитектура SharePoint была достаточно гибка, чтобы мы смогли настроить ее к нашим потребностям, не обращаясь к кодированию. То, что я предложил бы, - то, что Вы откладываете некоторое время для управления безотносительно решения, для которого Вы идете. Без обслуживания для репозитория документации очень легко стать или устаревшим или неорганизованным. Мы считали обязательным для себя обновление папок нашей команды в конце каждой Sprint работы (мы использовали Толпу гибкая методология).
Wikis являются прекрасной идеей для того, чтобы поделиться знаниями, возможно менее формальным способом. Я экспериментировал с использованием частного WetPaint wiki, но не получил закрытие сделки от управления. Однако это, конечно, стоит попытки. Вы не собираетесь уходить без потребности в редакционном управлении, но нет ничего неправильно с созданием этого аспекта общая ответственность между командами или выполнением его циклическим способом.
То, что я рекомендовал бы, является временем заказа в Ваших календарях для сессий обмена знаний. Это - все к легкому для зданий разработки большего размера для разделения на бункеры (не сознательно, но почти как побочный продукт необходимой специализации) и для этого для приведения к двум или больше командам, работающим над многими из тех же проблем. Ежемесячные или двухнедельные встречи с целой группой могут быть очень полезными. Презентации Videoed являются другой идеей, но должен быть баланс между ведением учета технических деталей и подготовкой, требуемой сделать это эффективно. (Мы никогда не успешно начинали это в моем предыдущем задании.)
Если бы Вы разделяетесь на малочисленные команды, я действительно рекомендовал бы ежедневные стоячие встречи, где все проходят то, чего они достигли в предыдущий день и что они планируют сделать сегодня. Это - один из ключей к Толпе, он держит всех в курсе действительно быстро, и он сохраняет много ненужных встреч и обзоров.
Я надеюсь, что это помогает.
Я видел collaboratives как Basecamp и Huddle, привыкший к большому эффекту здесь, внутренние wikis (и интранет в целом) имеют тенденцию быть слаборазвитыми и проигнорированными, по моему опыту.
Wikis являются большими. Они действительно должны быть структурированы, но я думаю, что самое большое препятствие в том, чтобы заставлять Wiki работать должно заставить людей на самом деле использовать его для записи релевантной информации.
В моем предыдущем задании у нас был внутренний канал IRC, который был очень полезен для микрокоммуникации. В моем текущем задании это не работает вообще; у очень немногих разработчиков есть привычка к использованию chatprogram в целях работы.
Для управления контентом мы раньше использовали сервер Zope с Plone и ZWiki. Мы теперь используем SharePoint 2007.
Мы также используем Бессмысленные данные для IM (мы - распределенная команда). IM хорош для того, чтобы быстро совместно использовать вещи с командой, но необходимо бояться злоупотреблять им, или Вы будете тонуть в шуме.