Складывается впечатление, что есть команда, которая ничего не хочет менять и меняться, а приходит злой менеджер и начинает мешать закрывать джирки, ещё и вопросы разные задаёт, потому что сам закрывать их не может )
По моему мнению, подобные ситуации вызваны как непониманием самого фреймворка (вполне вероятно, как менеджером, так и командой разработки) и простым нежеланием брать на себя ответственность. В скраме нет менеджера, есть dev team. И как раз задача команды каждый спринт - думать и меняться ради того, что бы сделать процесс разработки а. более предсказуемым, б. более оптимальным и в. качественным (и тут не про закрытие задач в трекере). Никто лучше самой команды этого сделать не сможет.
Факт того, что именно менеджер и есть скрам мастер, уже говорит о многом - отсутствии доверия и инициативы. Либо же компания (менеджер) не готова (не доверяет) больше делегировать команде, либо команда не готова брать на себя ответственность, а часто и то и другое.
Касательно тестирования результатов своего труда - один из ярких примеров нежелания и перекладывания ответственности, ее разделения в команде. Я как разработчик, не могу представить, что бы мог отдать работу на тестирование, не убедившись, что все в порядке. И это не дев тестирование успешных сценариев и не только вручную. Считаю, что так будет меньше сюрпризов именно в конце, уменьшает количество переключения контекста и делает меня счастливые ) Но QA действительно нужен.
Committed vs. completed, в скрам так же никто не вспоминает. Но это одна из метрик, которая косвенно может характеризовать процесс разработки, его предсказуемость. Разбиение на небольшие задачи, атомарные и частые деплои, кросс функциональные команды, написание интеграционных и функциональных тестов разработчиком, быстрая передача на тестирование, заведение spike задач, что бы лучше подготовиться к следующей итерации и т.д. - то, что обычно помогает. Но конечно, не везде и не всегда это панацея.
Нашел ваш блог. Довольно интересный, и, имхо, вот именно такого рода статей, более углубленных, как раз не хватает на хабре.
Так что, был бы рад почитать :)
В этом случае можно проще через volatile и Object result вместо массива :) Но это будет работать только в том случае, если наш aSync никогда не должен вернуть null.
Кстати зачем вообще BlockingQueue там, где мы используем CDL или CB? Да и в первом примере зачем List, если нам по-сути нужен просто один объект?
И вообще, из всех предложенных вариантов, ИМХО, самый «элегантный» — с Exchanger.
А вообще решение этой задачи можно развивать и развивать, как говориться, сколько умов — столько и решений :)
Да, у каждого потока может быть своя логика обработки InterruptedException, но т.к. вы используете стороннюю библиотеку, я думаю необходимо дать ей (библиотеке) решать что же в итоге делать и как на это событие реагировать т.к. у нее может быть как раз таки своя логика.
Добавьте четвертый пример: изменить queue.poll() на queue.take(), не игнорировать InterruptedException и убрать всю прочую синхронизацию на барьерах, CDL и т.д.
Да, был у нас такой предмет на первом курсе. Прикладная Теория Цифровых Автоматов (все его просто называли ПТиЦА:))
Вот только помниться там еще методы были, такие как метод Квайна, Квайна-Мак Класки, неопределенных коэффициентов…
Наверное один из самых толковых предметов, хотя казался невероятно сложным :)
1) Доступ к флешам клиентов я еще не проверял. Но видел на хабре статью о такой настройке. Нужно будет попробовать и проверить.
2) По поводу звука — я устанавливал на сервер пакет Ричарда Джоуна (rpm , tar)
3) По поводу печати на локальные принтеры — необходимости не было. Но можно будет протестировать, т.к. в документации к LTSP заявлено, что такая возможность есть.
Если данная тема действительно вас заинтересовала — то со временем напишу статью, в которой постараюсь ответить на все интересующие вас вопросы, а так же те, которые в ходе внедрения данного решения возникнут у меня.
Возможно я ошибаюсь, но как вы собираетесь реализовать терминальный сервер через VNC и SSH порт форвардинг? В лучшем случае вы получите защищенный удаленный сеанс. Я имею ввиду, что VNCServer не является менеджером сеансов и новый сеанс вам запустить не удастся. Для локальной сети в учебных классах использовать ssh я смысла не вижу. Из других возможных альтернатив — X11vnc и nx, если не изменяет память.
По сути можно было бы и самому собрать ядро для тонких клиентов с минимальным необходимым набором софта, но зачем изобретать велосипед?
Складывается впечатление, что есть команда, которая ничего не хочет менять и меняться, а приходит злой менеджер и начинает мешать закрывать джирки, ещё и вопросы разные задаёт, потому что сам закрывать их не может )
По моему мнению, подобные ситуации вызваны как непониманием самого фреймворка (вполне вероятно, как менеджером, так и командой разработки) и простым нежеланием брать на себя ответственность. В скраме нет менеджера, есть dev team. И как раз задача команды каждый спринт - думать и меняться ради того, что бы сделать процесс разработки а. более предсказуемым, б. более оптимальным и в. качественным (и тут не про закрытие задач в трекере). Никто лучше самой команды этого сделать не сможет.
Факт того, что именно менеджер и есть скрам мастер, уже говорит о многом - отсутствии доверия и инициативы. Либо же компания (менеджер) не готова (не доверяет) больше делегировать команде, либо команда не готова брать на себя ответственность, а часто и то и другое.
Касательно тестирования результатов своего труда - один из ярких примеров нежелания и перекладывания ответственности, ее разделения в команде. Я как разработчик, не могу представить, что бы мог отдать работу на тестирование, не убедившись, что все в порядке. И это не дев тестирование успешных сценариев и не только вручную. Считаю, что так будет меньше сюрпризов именно в конце, уменьшает количество переключения контекста и делает меня счастливые ) Но QA действительно нужен.
Committed vs. completed, в скрам так же никто не вспоминает. Но это одна из метрик, которая косвенно может характеризовать процесс разработки, его предсказуемость. Разбиение на небольшие задачи, атомарные и частые деплои, кросс функциональные команды, написание интеграционных и функциональных тестов разработчиком, быстрая передача на тестирование, заведение spike задач, что бы лучше подготовиться к следующей итерации и т.д. - то, что обычно помогает. Но конечно, не везде и не всегда это панацея.
Так что, был бы рад почитать :)
volatileиObject resultвместо массива :) Но это будет работать только в том случае, если нашaSyncникогда не должен вернутьnull.Кстати зачем вообще
BlockingQueueтам, где мы используемCDLилиCB? Да и в первом примере зачемList, если нам по-сути нужен просто один объект?И вообще, из всех предложенных вариантов, ИМХО, самый «элегантный» — с Exchanger.
А вообще решение этой задачи можно развивать и развивать, как говориться, сколько умов — столько и решений :)
InterruptedException, но т.к. вы используете стороннюю библиотеку, я думаю необходимо дать ей (библиотеке) решать что же в итоге делать и как на это событие реагировать т.к. у нее может быть как раз таки своя логика.queue.poll()наqueue.take(), не игнорироватьInterruptedExceptionи убрать всю прочую синхронизацию на барьерах, CDL и т.д.Вот только помниться там еще методы были, такие как метод Квайна, Квайна-Мак Класки, неопределенных коэффициентов…
Наверное один из самых толковых предметов, хотя казался невероятно сложным :)
2) По поводу звука — я устанавливал на сервер пакет Ричарда Джоуна (rpm , tar)
3) По поводу печати на локальные принтеры — необходимости не было. Но можно будет протестировать, т.к. в документации к LTSP заявлено, что такая возможность есть.
Если данная тема действительно вас заинтересовала — то со временем напишу статью, в которой постараюсь ответить на все интересующие вас вопросы, а так же те, которые в ходе внедрения данного решения возникнут у меня.
По сути можно было бы и самому собрать ядро для тонких клиентов с минимальным необходимым набором софта, но зачем изобретать велосипед?