Интересны некоторые комментарии здесь в духе «wikileaks изначально проект американского правительства с целью выложить компромат на Россию, а слив по Афганистану был для отвода глаз».
1) Я думаю никто не ставит под сомнение, что есть тонны сомнительных документов, публикация которых заставит чувствовать себя неуютно очень многих чиновников. Их и копать-то сильно не надо, с нашим отношением к безопасности информации.
2) Когда Навальный выкладывает документы — он молодец, а когда это делается из-за рубежа — это провокация и происки врагов? Имхо как раз замечательное проявление менталитета, когда «ругать своих можно только своим» (=«сор из избы не выносить»).
Если есть идея об «информационном обществе», «общественном контроле» и проч — почему общественный контроль от сайта wikileaks воспринимается как подстава?
Моё мнение — инфраструктуру проекта надо рассматривать целиком.
Можно набирать её из компонент (cvs,ci, багтрекер) и интегрировать, а можно (разумеется, если есть время-ресурсы) допилить одну из vcs под свои нужды. главное, чтобы всё вместе хорошо работало и было поддерживаемым.
> Ну а хранение в исходниках инструкций для системы сборки совсем уж не правильно. Это служебная, прикладная информация, она не имеет никакого отношения к коду.
вы наверное и аннотации не любите :) и инструкции не по сборке, а по менеджменту этого кода — кто может менять, что делать при изменениях, проч.
это как со конфигурацией Spring'a (я джавер) — можно вынести в XML, можно сделать аннотациями в коде. В коде имхо удобнее.
согласен, такие ситуации бывают, но в принципе это уже исключительная ситуация, типа «поменялись требования, тесты менять долго, а функционал нужен сейчас».
в таких случаях тесты помечаются как disabled, т.е. они по-прежнему видны в continuous integration, но не запускаются. А вот их обратное их включение — уже на совести того, кто отключил ;)
> О каких файлах идет речь?
Исходники. В заголовок файла дописывается комментарий с этими метками.
нет. обычно без правок, иногда 1-2 правки.
здравый смысл помогает не обращать внимания на code style (если конечно не совсем ужас-ужас) и мелкие проблемы типа naming convention.
опять-таки, можно просто написать все замечания и сказать «ок» — тогда и код закоммитится, и человек отзыв на свой код получит (и возможно поправит при следующем коммите)
ну, практически получается задержка в 20-30 секунд перед коммитом — что имхо приемлемо (как раз за это время успеешь ещё раз подумать — всё ли правильно коммитится))
время на ревью — открыть ссылку из почты, просмотреть изменения, нажать кнопочку «согласен» или написать «кг-ам» в комментариях. задержка ревью обычно 5-30 минут.
я не навязываю, просто для нашего проекта-группы это работает. у вас может быть другой проект и другие реалии.
да, это замедляет попадание кода в эталонный репозиторий, нокачество кода улучшается значительное — все знают, что незаметно хак/лажу закоммитить не получится.
> А можно поинтересоваться насчет времени прохождения тестов перед закладкой?
Тесты помечены тагами. Перед коммитом запускаются те, которые не имеют тагов типа «integration» или «slow». Соотсветсвенно есть возможность регулировать компромисс между coverage и временем коммита.
> Как осуществляется выбор того, кто должен проводить ревью кода?
В заголовке файлов есть поля, которые парсятся при коммите.
Поля типа:
— email'ы разработчиков/группы разработчиков, кто может делать code review / approval
— email'ы группы, куда пост-коммит отсылаются diff'ы-уведомления
— Test suites, которые будут запускаться (кроме testsuit'ов по умолчанию)
и проч.
также всё это можно указать в отдельном файле со специальным именем, тогда настройки будут действовать для всех файлов в директории.
Звучит страшно, но по факту пользоваться удобно, тк за несколько лет было хорошо допилено:
— дешевые бранчи, приемлемый merge
— удобный gui
— локально ничего не хранится — можно на машине коллеги за секунду переключиться в свой workspace и вместе с ним продолжить работать над незакоммиченными изменениями
встроенная поддержка:
— code review
— run-tests-before-commit — нельзя закоммитить что-то, что ломает тесты
— second-pair-of-yes check — все коммиты для релиза должны быть подтверждены кем-то еще, кроме разрабочка
То есть, что хорошо сделано — поддержка тех самых agile software development best practices на уровне VCS.
Каких-то из них поддерживаются в рекомендательном виде: зарелизить без second-pair-of-yes check можно, но всем будут разосланы емайлы с большими красными буквами — то есть на это надо иметь хорошую причину (типа всё упало ночью и нужен срочный багфикс).
Другие поддерживаются в обязательном порядке — нельзя закоммитить что-то, что ломает тесты, нельзя закоммитить изменения в самые критичные файлы без code review.
Именно. Сейчас уже не вспомню, что были за косяки при установке 8i/9, но как раз из разряда тех что описывает автор. То есть — где-то вылетает ошибка, которая не ошибка, где-то надо указать путь к только что установленной БД (из предыдущего окошка), дурацкие значения по умолчанию, и проч.
Раньше приходилось много работать с Ораклом, и получалось как в том анекдоте — «дети у вас красивые, а всё, что вы делаете руками — очень, очень плохо...» Сама БД — отличная, а всё, что вокруг неё (включая все java-продукты) — ужасное и тормозное bloatware.
Может что-то и изменилось за 5 лет, но судя по нынешних отзывам — изменилось немного.
Не то чтобы несовместимые, просто цели у них разные.
У бизнеса цель — заработать деньги, а не писать программы.
Соотсветсвенно с точки зрения бизнеса идеальный модуль, это модуль, максимизирующий формулу «доходОтИспользования — затратыНаНаписание — затратыНаПоддержку» (упрощённо).
И никакие доводы о важности и полезности «искусства программирования» не помогут, если «доходОтИспользования» невелик.
Извините конечно, но линейная регрессия (или то, что вы назвали модным словом «тренд») в данном случае неприменима — налицо структурный сдвиг в районе 2008 года.
В общем, опять подтасовывания статистических выводов. Не говоря уже о том, что желтые точки УЖЕ представляют собой прогноз стоимости — то есть регрессию надо делать по ним.
В общем, картинка пригодится только в желтой прессе. Я бы просто постенялся такое постить.
Потому что концепция Technical Debt (http://www.martinfowler.com/bliki/TechnicalDebt.html) принадлежит «светлой стороне силы», уменьшение долга улучшает код в отличие от остальных приведенных методов.
Исследования проводят не идиоты, а вот результаты исследования могут быть «интерпретированы» маркетологами, в частности, с целью получения громких заголовков.
опять-таки без исходных данных рассуждать бессмысленно.
не гауссовское там распределние. оно будет гауссовским для ответов «играю-нет» среду людей одного возраста, а не разных возрастов.
по-другому: если распределение гауссовское в промежутке 18-49, то почему бы ему не быть гауссовским в промежутке 10-90? таким образом средний вораст геймера будет 50.
Возможно действительно докапываюсь, и исходные данные были другие.
Интересно, они средний возраст получили исходя из того, что наибольшая часть принадлежит к категории 18-49, то есть, в среднем 33.5 (19+49)/2?
Это бред — подразумевается равномерое распредление внутри этой категории. А если 90% из этой составляет группа 18-22, к примеру, то средний возраст никак не будет 34.
другой вариант — исходных данных так и не представили, и на 1ой диаграмме уже промежуточные данные.
Вот именно «листик за листиком» у меня не совсем аккуратно вышло…
Попробовал обрабатывать края разными способами на двух книгах, потом забил и оставлял везде эту самую ёлочку ;)
Тем, кто считает, что это напрасная трата времени: после 2ой книги весь процесс занимает 2-3 часа на книгу в 500 страниц, от форматирования PDF буклетами до готовой книжки.
Нехорошо конечно так говорить, но когда в инете лежат типографские PDF'ы, а книжка стоит от 50 фунтов и выше (70 долларов скажем) — то в общем-то потратить 2-3 часа вполне себе стоит.
PS: Печатаю на Samsung ML2850 — по-моему, один из самых дешевых лазерников с двухсторонней печатью, ещё и сетевой к тому же.
А как обрабатываете внешние боковые стороны страниц?
Если печатать буклетами по 16 страниц сбоку в профиль получается примерно такая «ёлочка»: /\/\/\/\/\/\
Я пытался обрезать, но даже при помощи специальных ножей-гильотин для бумаги не получается сделать ровно — потому что нужно резать книгу в сложенном состоянии, что ни для одного доступного ножа является неппосильной задачей.
Есть мысль обработать в спрессованном состоянии мелкой шкуркой (которая на дрель насаживается) — но пока опробовать не получилось.
1) Я думаю никто не ставит под сомнение, что есть тонны сомнительных документов, публикация которых заставит чувствовать себя неуютно очень многих чиновников. Их и копать-то сильно не надо, с нашим отношением к безопасности информации.
2) Когда Навальный выкладывает документы — он молодец, а когда это делается из-за рубежа — это провокация и происки врагов? Имхо как раз замечательное проявление менталитета, когда «ругать своих можно только своим» (=«сор из избы не выносить»).
Если есть идея об «информационном обществе», «общественном контроле» и проч — почему общественный контроль от сайта wikileaks воспринимается как подстава?
Интересно, что они выложат.
Моё мнение — инфраструктуру проекта надо рассматривать целиком.
Можно набирать её из компонент (cvs,ci, багтрекер) и интегрировать, а можно (разумеется, если есть время-ресурсы) допилить одну из vcs под свои нужды. главное, чтобы всё вместе хорошо работало и было поддерживаемым.
> Ну а хранение в исходниках инструкций для системы сборки совсем уж не правильно. Это служебная, прикладная информация, она не имеет никакого отношения к коду.
вы наверное и аннотации не любите :) и инструкции не по сборке, а по менеджменту этого кода — кто может менять, что делать при изменениях, проч.
это как со конфигурацией Spring'a (я джавер) — можно вынести в XML, можно сделать аннотациями в коде. В коде имхо удобнее.
в таких случаях тесты помечаются как disabled, т.е. они по-прежнему видны в continuous integration, но не запускаются. А вот их обратное их включение — уже на совести того, кто отключил ;)
> О каких файлах идет речь?
Исходники. В заголовок файла дописывается комментарий с этими метками.
здравый смысл помогает не обращать внимания на code style (если конечно не совсем ужас-ужас) и мелкие проблемы типа naming convention.
опять-таки, можно просто написать все замечания и сказать «ок» — тогда и код закоммитится, и человек отзыв на свой код получит (и возможно поправит при следующем коммите)
время на ревью — открыть ссылку из почты, просмотреть изменения, нажать кнопочку «согласен» или написать «кг-ам» в комментариях. задержка ревью обычно 5-30 минут.
я не навязываю, просто для нашего проекта-группы это работает. у вас может быть другой проект и другие реалии.
да, это замедляет попадание кода в эталонный репозиторий, нокачество кода улучшается значительное — все знают, что незаметно хак/лажу закоммитить не получится.
но времени тесты и review занимают немного — писать код всё равно медленнее, чем читать и запускать ;)
Тесты помечены тагами. Перед коммитом запускаются те, которые не имеют тагов типа «integration» или «slow». Соотсветсвенно есть возможность регулировать компромисс между coverage и временем коммита.
> Как осуществляется выбор того, кто должен проводить ревью кода?
В заголовке файлов есть поля, которые парсятся при коммите.
Поля типа:
— email'ы разработчиков/группы разработчиков, кто может делать code review / approval
— email'ы группы, куда пост-коммит отсылаются diff'ы-уведомления
— Test suites, которые будут запускаться (кроме testsuit'ов по умолчанию)
и проч.
также всё это можно указать в отдельном файле со специальным именем, тогда настройки будут действовать для всех файлов в директории.
Звучит страшно, но по факту пользоваться удобно, тк за несколько лет было хорошо допилено:
— дешевые бранчи, приемлемый merge
— удобный gui
— локально ничего не хранится — можно на машине коллеги за секунду переключиться в свой workspace и вместе с ним продолжить работать над незакоммиченными изменениями
встроенная поддержка:
— code review
— run-tests-before-commit — нельзя закоммитить что-то, что ломает тесты
— second-pair-of-yes check — все коммиты для релиза должны быть подтверждены кем-то еще, кроме разрабочка
То есть, что хорошо сделано — поддержка тех самых agile software development best practices на уровне VCS.
Каких-то из них поддерживаются в рекомендательном виде: зарелизить без second-pair-of-yes check можно, но всем будут разосланы емайлы с большими красными буквами — то есть на это надо иметь хорошую причину (типа всё упало ночью и нужен срочный багфикс).
Другие поддерживаются в обязательном порядке — нельзя закоммитить что-то, что ломает тесты, нельзя закоммитить изменения в самые критичные файлы без code review.
Раньше приходилось много работать с Ораклом, и получалось как в том анекдоте — «дети у вас красивые, а всё, что вы делаете руками — очень, очень плохо...» Сама БД — отличная, а всё, что вокруг неё (включая все java-продукты) — ужасное и тормозное bloatware.
Может что-то и изменилось за 5 лет, но судя по нынешних отзывам — изменилось немного.
У бизнеса цель — заработать деньги, а не писать программы.
Соотсветсвенно с точки зрения бизнеса идеальный модуль, это модуль, максимизирующий формулу «доходОтИспользования — затратыНаНаписание — затратыНаПоддержку» (упрощённо).
И никакие доводы о важности и полезности «искусства программирования» не помогут, если «доходОтИспользования» невелик.
Вот здесь очень хорошая статья на эту тему (на английском.
В общем, опять подтасовывания статистических выводов. Не говоря уже о том, что желтые точки УЖЕ представляют собой прогноз стоимости — то есть регрессию надо делать по ним.
В общем, картинка пригодится только в желтой прессе. Я бы просто постенялся такое постить.
Потому что концепция Technical Debt (http://www.martinfowler.com/bliki/TechnicalDebt.html) принадлежит «светлой стороне силы», уменьшение долга улучшает код в отличие от остальных приведенных методов.
опять-таки без исходных данных рассуждать бессмысленно.
по-другому: если распределение гауссовское в промежутке 18-49, то почему бы ему не быть гауссовским в промежутке 10-90? таким образом средний вораст геймера будет 50.
Возможно действительно докапываюсь, и исходные данные были другие.
Еще раз прочитал — не нашел откуда взялась цифра 34.
Повторюсь — возможно, в первой диаграмме уже усреднённые данные, в таком случае цифра 34 может быть верной.
Это бред — подразумевается равномерое распредление внутри этой категории. А если 90% из этой составляет группа 18-22, к примеру, то средний возраст никак не будет 34.
другой вариант — исходных данных так и не представили, и на 1ой диаграмме уже промежуточные данные.
Попробовал обрабатывать края разными способами на двух книгах, потом забил и оставлял везде эту самую ёлочку ;)
Тем, кто считает, что это напрасная трата времени: после 2ой книги весь процесс занимает 2-3 часа на книгу в 500 страниц, от форматирования PDF буклетами до готовой книжки.
Нехорошо конечно так говорить, но когда в инете лежат типографские PDF'ы, а книжка стоит от 50 фунтов и выше (70 долларов скажем) — то в общем-то потратить 2-3 часа вполне себе стоит.
PS: Печатаю на Samsung ML2850 — по-моему, один из самых дешевых лазерников с двухсторонней печатью, ещё и сетевой к тому же.
А как обрабатываете внешние боковые стороны страниц?
Если печатать буклетами по 16 страниц сбоку в профиль получается примерно такая «ёлочка»: /\/\/\/\/\/\
Я пытался обрезать, но даже при помощи специальных ножей-гильотин для бумаги не получается сделать ровно — потому что нужно резать книгу в сложенном состоянии, что ни для одного доступного ножа является неппосильной задачей.
Есть мысль обработать в спрессованном состоянии мелкой шкуркой (которая на дрель насаживается) — но пока опробовать не получилось.