Comments 25
clnt = new jabber.client.JabberClient ()
Мне всегда было интересно, в чём тайный смысл выбрасывать гласные буквы из названий переменных? Неужели
clnt чем-то лучше, чем client?client = new jabber.client.JabberClient ()
Если есть класс client, то переменную можно назвать cln clnt. С полным именем букв больше и писать уже нужно с разными префиксами/постфиксами, например, client_* а сокращать до гласных звучит некрасиво — clie
Классы вообще-то с большой буквы начинаются: Client.
В одной библиотеке вообще крайности в этом плане видел:
Возможно автору оно кажется понятным, но я когда вижу такой ужас — сильно ломаю себе голову и глаза. И таки не вижу в чём проблема в топике было написать так, ведь слово
В одной библиотеке вообще крайности в этом плане видел:
grdntsnptrnsВозможно автору оно кажется понятным, но я когда вижу такой ужас — сильно ломаю себе голову и глаза. И таки не вижу в чём проблема в топике было написать так, ведь слово
client ни с чем не конфликтует:client = new jabber.client.JabberClient ()
У нх здсь свяо атмсфера.
нх здс св тмсфр
И ещё никто про иврит не пошутил?
Кажется, нет. Давай!
Сомневаюсь в том, что комментирующие в курсе особенностей еврейской письменности и других примеров консонантного письма.
Часто так сокращаю локальные «одноразовые» переменные, т.к. это уменьшает объем кода — особенно там, где одна переменная появляется в одной и той же строчке более одного раза.
Сам прием может быть вполне оправданным, вопрос в том, как его использовать.
Сам прием может быть вполне оправданным, вопрос в том, как его использовать.
А смысл так сокращать объём кода? Не надо делать работу обфускатора заранее.
Вопрос не в килобайтах, конечно. Часто улучшает читабельность — когда сокращение достаточно интуитивно + значение переменной понятно из контекста, а на выходе мы получаем, ну, скажем, уменьшение длины строчки кода на 5-10 символов. Меньше проблем с полосами прокрутки, разбивкой строк на несколько, просто беганьем глазами от начала до конца строки и т.д.
Особенно актуально для Java, где длина строчки кода имеет свойство разрастаться до каких-то совершенно неприличных (и нечитабельных, да) объемов.
Особенно актуально для Java, где длина строчки кода имеет свойство разрастаться до каких-то совершенно неприличных (и нечитабельных, да) объемов.
Локальная «одноразовая» встречается в одной строчке несколько раз… назовите её «a».
Хм…
Берем Hudson на котором создаем проекты по сборке, статическому анализу и, например, развертыванию в тестовом окружении. Поднимаем ноды (сборочная/тестовая машина/машины и т.п.), например, по ssh, а в настройках проекта указываем, какие ноды при этом задействовать. Нотификация и аутентификация по вкусу.
И в виде стандартного решения получаем распределении нагрузки по нодам при централизованное управлении.
Берем Hudson на котором создаем проекты по сборке, статическому анализу и, например, развертыванию в тестовом окружении. Поднимаем ноды (сборочная/тестовая машина/машины и т.п.), например, по ssh, а в настройках проекта указываем, какие ноды при этом задействовать. Нотификация и аутентификация по вкусу.
И в виде стандартного решения получаем распределении нагрузки по нодам при централизованное управлении.
Централизованное управление как раз то, чего хотелось избежать. Суть не в распределении нагрузки — она решается различными способами. Например, IncrediBuild-ом и ему подобными системами распараллеливания вычислений. Цель как раз децентрализация управления. Части народа из QA вообще в процессе работы не нужно общаться со сборочным сервером, и не хочется каждую задачу тестирования создавать на Hudson-е. А комбинацией параметров команды можно запустить множество различных конфигураций тестирования.
Ну не знаю…
В Jenkins, располагая вычислительными средствами и имея определенные задачи, я без труда могу управлять правами пользователей, задавать зависимости проектов, а так же создавать как параметризованные так и мульти-конфигурационные проекты и много другое. Благодаря этому ряд вопросов решается, так сказать, сам собой.
Например:
— пользователь Х должен иметь право запускать задачу на сборку проекта, в случае успешной сборки которого, автоматически запустится задача по его разворачиванию;
— предоставить возможность пользователю при запуске сборки определить параметры сборки (например Debug/Release), но при этом не иметь доступа к исходным кодам;
— пока идет сборка проекта А на ноде N, никакие проекты не запускать, а предварительно собрать проект C.
А как эти задачи будете решать вы?
Минусы? Да согласен проектов становиться очень много, но это не беда — создаются «вьюхи» где группируются проекты по смыслу и назначаются в качестве дефолтных соответствующим пользователям.
Но зато плюсы: простота реализации и администрирования.
В Jenkins, располагая вычислительными средствами и имея определенные задачи, я без труда могу управлять правами пользователей, задавать зависимости проектов, а так же создавать как параметризованные так и мульти-конфигурационные проекты и много другое. Благодаря этому ряд вопросов решается, так сказать, сам собой.
Например:
— пользователь Х должен иметь право запускать задачу на сборку проекта, в случае успешной сборки которого, автоматически запустится задача по его разворачиванию;
— предоставить возможность пользователю при запуске сборки определить параметры сборки (например Debug/Release), но при этом не иметь доступа к исходным кодам;
— пока идет сборка проекта А на ноде N, никакие проекты не запускать, а предварительно собрать проект C.
А как эти задачи будете решать вы?
Минусы? Да согласен проектов становиться очень много, но это не беда — создаются «вьюхи» где группируются проекты по смыслу и назначаются в качестве дефолтных соответствующим пользователям.
Но зато плюсы: простота реализации и администрирования.
Простота администрирования… Как раз мне кажется в данном случае сложность администрирования. Как Вы справедливо заметили, число проектов не упрощает процесс.
Простота реализации… Собственно наш способ он тоже не такой сложный. А поддержка постоянно меняющихся конфигураций стоит в Вашем случае больше. Ну а готовые фичи Jenkinsa (или, например, Bamboo, который захотели попробовать наши коллеги из смежного подразделения) никто же не отменяет. Вполне возможно, что мы придем в итоге к нескольким готовым CI в цепочке, дабы не лишать никого возможности поэкспериментировать.
По порядку:
1. Именно такую задачу мы и решаем, напрмер команда build /trunk /deploy, в случае успешной сборки BuildServer передает управление на DeployServer.
2. Ограничить доступ к исходникам — очень актуальная задача для нас. Правда не совсем понимаю при чем тут разные конфигурации.
Запуск проекта с разными конфигурациями — это собственно все так же, на обработчике Jabber сообщений, есть конфигурация по умолчанию, при указании конкретной конфигурации она передается собственно платформе сборке, в нашем случае msbuild. Проблема связанная с безопасностью исходников существует в таком виде, что на сборщике хранится весь код, и нужно исключить возможность внедрения инъекции в допустим vcproj (хотя они делаются cmake-ом, но не в этом суть) в виде, например, prebuild-step-ов. Это решается двумя путями:
— ограничением прав локальной учетной записи, под которой выполняется сборка
— и собственно отсутствием какого-либо файлового доступа на BuildServer, внедренный код не сможет выложить исходники никуда далее этой машины (тем более по локалке), а на Storage выкладываются файлы только по опреденным правилам и проверкам
3.Если это A и С — это подпроекты в общем проекте и С является зависимостью A, то решение на уровне проекта, допустим так
Но скорее всего Вы про отдельные проекты, которые не всегда стоит запускать по порядку.
Тогда, не дорабатывая ничего, у нас это решится так:
build /C build /A, управление после сборки одного проекта передастся опять на BuildServer
А паралеллятся не проекты между собой, а один проект (я имею ввиду проект в широком смысле, содержащий некоторое количество vcproj-ей, csprojt-ей и т.д.)
Даже если vcproj один, то распараллеляться cl-подпроцессы, и только линкер будет идти в один поток — это решается технологией unitybuild, успешно внедренной.
Простота реализации… Собственно наш способ он тоже не такой сложный. А поддержка постоянно меняющихся конфигураций стоит в Вашем случае больше. Ну а готовые фичи Jenkinsa (или, например, Bamboo, который захотели попробовать наши коллеги из смежного подразделения) никто же не отменяет. Вполне возможно, что мы придем в итоге к нескольким готовым CI в цепочке, дабы не лишать никого возможности поэкспериментировать.
По порядку:
1. Именно такую задачу мы и решаем, напрмер команда build /trunk /deploy, в случае успешной сборки BuildServer передает управление на DeployServer.
2. Ограничить доступ к исходникам — очень актуальная задача для нас. Правда не совсем понимаю при чем тут разные конфигурации.
Запуск проекта с разными конфигурациями — это собственно все так же, на обработчике Jabber сообщений, есть конфигурация по умолчанию, при указании конкретной конфигурации она передается собственно платформе сборке, в нашем случае msbuild. Проблема связанная с безопасностью исходников существует в таком виде, что на сборщике хранится весь код, и нужно исключить возможность внедрения инъекции в допустим vcproj (хотя они делаются cmake-ом, но не в этом суть) в виде, например, prebuild-step-ов. Это решается двумя путями:
— ограничением прав локальной учетной записи, под которой выполняется сборка
— и собственно отсутствием какого-либо файлового доступа на BuildServer, внедренный код не сможет выложить исходники никуда далее этой машины (тем более по локалке), а на Storage выкладываются файлы только по опреденным правилам и проверкам
3.Если это A и С — это подпроекты в общем проекте и С является зависимостью A, то решение на уровне проекта, допустим так
<?xml version="1.0" encoding="windows-1251"?>
...
Но скорее всего Вы про отдельные проекты, которые не всегда стоит запускать по порядку.
Тогда, не дорабатывая ничего, у нас это решится так:
build /C build /A, управление после сборки одного проекта передастся опять на BuildServer
А паралеллятся не проекты между собой, а один проект (я имею ввиду проект в широком смысле, содержащий некоторое количество vcproj-ей, csprojt-ей и т.д.)
Даже если vcproj один, то распараллеляться cl-подпроцессы, и только линкер будет идти в один поток — это решается технологией unitybuild, успешно внедренной.
Берём ботнет IRC-серверов, назначаем каналы каждому отделу, софт пусть общается по telnet. Profit!
Критика в сторону написания статьи:
Я не знаком был с аббревиатурой CI и большой первый абзац прошел как шум ни о чем до самого конца, где все же есть объяснение «единственный сервер для сборки».
Я не знаком был с аббревиатурой CI и большой первый абзац прошел как шум ни о чем до самого конца, где все же есть объяснение «единственный сервер для сборки».
Есть причины, почему джаббер, а не емейл, например? ;)
Джаббер — потому что просто и быстро, и Miranda была у всех на машинах, и потом в почту не так оперативно читать и писать.
Но направление мыслей у нас с Вами сходится :-) Сейчас у нас активно внедряют MS Lync как стандарт корпоративной связи, для которого предусмотрен Lync 2010 SDK, с помощь которого мы научим наш CI понимать кроме джаббера и Lync. И тогда появzтся дополнительные возможности интеграции с Exchange, управление CI из Outlook, сохранение пропущенных результатов и т.д.
Но направление мыслей у нас с Вами сходится :-) Сейчас у нас активно внедряют MS Lync как стандарт корпоративной связи, для которого предусмотрен Lync 2010 SDK, с помощь которого мы научим наш CI понимать кроме джаббера и Lync. И тогда появzтся дополнительные возможности интеграции с Exchange, управление CI из Outlook, сохранение пропущенных результатов и т.д.
Sign up to leave a comment.
Непрерывная интеграция с помощью Jabber. Изобретаем велосипед?