Даже если БЫ регулярные выражения проигрывали, для эффективности алгоритма надо было бы после
$isName = false;
ставить break;
Во избежание проверки всех последующих элементов. Это было БЫ хоть как-то похоже на правду... А так максимально неоптимальный вариант. Хоть в книжку по алгоритмам вставля
Ага. Вообще поиск в стиле GTalk оказывается удобнее групп. В случае, если помнишь как зовётся контакт... а бывает что помнишь только примерно к чему относится, без подробностей. Для решения этой проблемы надо подумать над грамотным переименованием - спасибо за наводку :)
Да, вроде помогло. Что-то где-то зарегистрировалось.
Из аськи вышибло. Сижу и жду того волшебного "вуаля", когда контакты появятся. Минут 15 уже жду...
У меня при попытке "Service Discovery" получается сообщение:
There was an error getting agents from gmail.com
Reason: Feature not implemented.
The feature requested is not implemented by the recipient or server and therefore cannot be processed.
Это если выключен флажок "Auto browse into objects" и включён "Automatically get item information".
Если первый флажок установить "On" молча что-то шуршит и ничего не показывает.
Ну так, небось, скорость "ветра" регулируема? Никто не заставляет использовать всё время максимальную нагрузку?
Думаю, при этом и потребление энергии может быть уменьшено.
А чего собственно не хватает в JIRA для того, чтобы её можно было расценивать как систему управления проектами?
Релизы суть те же итерации (или спринты). По каждому релизу можно увидеть статистику, которая позволяет прогнозировать время последующих релизов. Есть огромное количество плагинов, которые помогают заниматься именно планированием.
Опять же при совмещении JIRA с Confluence получаем прекрасный инструмент для документирования как релизов так и продуктов.
А в том же Trac это всё так и вовсе на нативном уровне - каждая задачка как wiki документ.
Я не хаю, естественно, этот новый и красивый Acunote просто пытаюсь найти чего же в нём такого нового и положительного :)
Речь не о том. Для того, чтобы поменять привычную систему на какую-то другую нужны какие-то весомые плюсы. Здесь я их не вижу. Вот и интересно то ли я проглядел, то ли их и нету?
Попробовал. В данный момент пользуюсь чисто средствами JIRA.
Создаётся странное впечатление, что это чисто надстройка, добавляющая рюшечки к существующей JIRA системе. Ничего принципиально нового и особо полезного по сравнению с JIRA кроме AJAX не обнаружил. Также не нашёл некоторых фич, которые наличествуют в JIRA.
А если на странице много компонентов, каждый из которых содержит собственные ссылки/кнопки или другие элементы, для которых нужно обрабатывать события? Если каждый будет развешивать свои обработчики на document.body помойка получится.
Имхо каждый сверчок должен знать свой шесток то бишь выше своего контейнера не подниматься.
К тому же, даже при использовании этого общего способа, логично было бы использовать 'attachEvent' (опять же со всеми требуемыми финтами для разных браузеров), а не буквальное определение одного обработчика. Не надо жадничать другим скриптам тоже может оказаться потребен 'window.load'.
Дальше. Функция function getEventTarget(e) в данной интерпретации явно предназначена исключительно для обработки событий, происходящих над ссылками. Причём ссылками, у которых установлен атрибут "href". Я бы предложил либо переименовать её, либо сделать методом 'MMNav', чтобы избежать конфликта имён. Да и просто инкапсулировать частную функциональность в конкретном классе.
Шпасиба за поправк
$isName = false;
ставить break;
Во избежание проверки всех последующих элементов. Это было БЫ хоть как-то похоже на правду... А так максимально неоптимальный вариант. Хоть в книжку по алгоритмам вставля
Перебрал ещё десяток транспортов вроде добился. Контакты засосались, однако GTalk не поддерживает группы????
Из аськи вышибло. Сижу и жду того волшебного "вуаля", когда контакты появятся. Минут 15 уже жду...
There was an error getting agents from gmail.com
Reason: Feature not implemented.
The feature requested is not implemented by the recipient or server and therefore cannot be processed.
Это если выключен флажок "Auto browse into objects" и включён "Automatically get item information".
Если первый флажок установить "On" молча что-то шуршит и ничего не показывает.
Возможно, "слабое подобие левой руки", но всё же...
Думаю, при этом и потребление энергии может быть уменьшено.
Релизы суть те же итерации (или спринты). По каждому релизу можно увидеть статистику, которая позволяет прогнозировать время последующих релизов. Есть огромное количество плагинов, которые помогают заниматься именно планированием.
Опять же при совмещении JIRA с Confluence получаем прекрасный инструмент для документирования как релизов так и продуктов.
А в том же Trac это всё так и вовсе на нативном уровне - каждая задачка как wiki документ.
Я не хаю, естественно, этот новый и красивый Acunote просто пытаюсь найти чего же в нём такого нового и положительного :)
Создаётся странное впечатление, что это чисто надстройка, добавляющая рюшечки к существующей JIRA системе. Ничего принципиально нового и особо полезного по сравнению с JIRA кроме AJAX не обнаружил. Также не нашёл некоторых фич, которые наличествуют в JIRA.
Так в чём же всё таки смысл?
Имхо каждый сверчок должен знать свой шесток то бишь выше своего контейнера не подниматься.
К тому же, даже при использовании этого общего способа, логично было бы использовать 'attachEvent' (опять же со всеми требуемыми финтами для разных браузеров), а не буквальное определение одного обработчика. Не надо жадничать другим скриптам тоже может оказаться потребен 'window.load'.
Дальше. Функция function getEventTarget(e) в данной интерпретации явно предназначена исключительно для обработки событий, происходящих над ссылками. Причём ссылками, у которых установлен атрибут "href". Я бы предложил либо переименовать её, либо сделать методом 'MMNav', чтобы избежать конфликта имён. Да и просто инкапсулировать частную функциональность в конкретном классе.
Так не бойся, милая, глянь в ноделист,
Возможно, тебя ожидает сюрприз,
Ведь нода моя - не СМ,
И модемом звонить среди дня
Ты поверь мне, не надо.
Ведь и слово "превед" бралось для рассмотрения именно ввиду яркости и очевидности сего образа, разве нет?