"Непрерывная интеграция" — практика разработки программ, при которой члены команды интегрируют свою работу очень часто (как правило, каждый интгерирует раз в день, что дает несколько интеграций в день). Каждая интеграция проверяется автоматической сборкой (включая тесты), чтобы обнаружить возможные ошибки как можно раньше. Многие команды обнаружили, что такой подход приводит к существенному уменьшению проблем интеграции. и позволяет команде разрабатывать совместный проект намного быстрее. Эта статья — краткий обзор непрерывной интеграции, описывающая эту технику и ее текущее использование.
В отличном коммунальном блоге O'Reilly Radar продолжается серия статей Database Wars (об использовании баз данных в современных крупных Web2.0 приложениях). На данный момент серия состоит из следующих статей:
* Web 2.0 and Databases Part 1: Second Life
Начало серии, зародившейся у Тима О'Рейлли после MySQL User Conference. Изначально идея была в том, чтобы опросить знакомых хозяев веб2.0 сервисов на тему — как они используют базы данных. В этой серии — авторы Second Life расскажут, как они начинали с Одной Большой Главной Базы Данных, и к чему это их привело.
* Database War Stories #3: Flickr
Кэл Хендерсон из Flickr объяснит, почему фолксономии и облака тегов плохо ложаться на нормализованную БД и как они с этим справляются.
* Database War Stories #4: NASA World Wind
Патрик Хоган — о том, как в NASA-вском аналоге Google Earth, World Wind доказала свою несостоятельность идея использования файловой системы (на больших количествах файлов).
* Database War Stories #5: craigslist
Эрик Шейд из craiglist делится секретом, как удачная архитектура помогает фирме из всего 19 сотрудников справляться с огромным и жутко посещаемым сервисом.
* Database War Stories #6: O'Reilly Research
Роджер Могулас — обо всяких интересных уроках, полученных в лабораториях O'Reilly Research — не только о БД, но и об обработке неструктурированной информации, проблемах интернационального мира и несоответствии традиционных БД задачам business intelligence.
В объектно-ориентированных языках типы данных легко расширяемы через наследование, но тяжело добавить новые функции. В функциональных языках — новые функции добавляются элементарно, но расширение данных требует модификации существующего кода. Проблема расширяемости одновременно функций и данных известна как expression problem. В документе ниже показана концепция открытых типов и открытых функций как легковесное решение expression problem на Haskell.
Принцип "меньше" от 37signals
Джейсон из компании 37signals прочитал на конференции Web 2.0 неофициальный доклад о принципе "меньше", предложив целых пять способов сэкономить: Меньше денег. Обычно Вы пишете бизнес-план и получаете немного денег. Это плохой способ. В конце концов Вы остаетесь с долгами, которые всегда являются злом. Аппаратное обеспечение настолько дешево, что можно считать его бесплатным. За деньги нельзя купить страсть. Все, что Вы на них можете — нанять людей и платить им зарплату. Возможно Вам просто нужно меньше людей. Меньше людей. Я думаю троих вполне достаточно. Если Вы думаете, что Вам нужно больше разработчиков, значит Ваш продукт слишком сложен. Обойдитесь дизайнером, разработчиком и менеджером, который будет связующим звеном между ними и сможет влиять на продукт в целом. Меньше времени. Работайте меньше. Это позволит Вам сосредоточиться на действительно важных вещах. Меньше абстракций. Просто создавайте продукт, обучаясь в процессе работы. Избавьтесь от утомительного составления спецификаций. Вместо этого начинайте разработку с пользовательского интерфейса, учитывая опыт пользователя. Это — то, что формирует Ваш продукт: опыт клиента. Меньше программного обеспечения. Меньше особенностей, меньше работы для технической поддержки. Делайте простые вещи, такие как del.icio.us или upcoming.org. Не решайте сложные проблемы. Есть очень много простых задач, которые только и ждут своих первооткрывателей.
Есть только одна вещь, которой должно быть больше: ограничения. Все вышеупомянутое подведет Вас к качественному результату.
PS: "зачем я это делаю?" — может возникнуть вопрос (тем более, после пафосного заявления об "уходе с RSDN").
Я кидаю сюда статьи, которые:
а) Как правило, новые (я мониторю очень много rss-ок)
б) Как правило, на английском (значительные русскоязычные статьи все и так замечают)
в) Были мне очень интересны или заставили change my mind
Целей при этом несколько:
а) Бескорыстное стремление к распространению знаний
б) Вызвать (возможно, интересное) обсуждение
в) Создать базу для дальнейших дискуссий на сходные темы ("Как уже обсуждалось в ветке такой-то...")
PPS: возможно, стоит каждый отдельный набор ссылок (или даже каждую ссылку) отдельным постом — для разделения обсуждения. Но пока обсуждений особых не вижу, поэтому пусть будет так.
Пара новых статей у Фаулера: CodeOwnership — об основных типах владения кодом: сильное, слабое, коллективное. ShiftingToCodeOwnership — история о том, почему в некоторых случаях приходится выбирать слабое владение кодом вместо коллективного (предпочтительного в рамках XP)
Ontological Representations of Software Patterns
Научная статья; обсуждается развитие Software Patterns, необходимость средств (tools) поддержки выделения и организации паттернов, а также возможный эффект от появления таких средств. Abstract и ссылка на PDF
Пара статей на Lifehacker.com (вообще весьма достойное чтиво):
1. Geek to Live: List your life in .txt
Предлагается структура для использования обычного txt-файла в качестве планировщика и todo-листа
2. Geek to Live: Script your life in .txt
Предлагается набор bash-скриптов для управления этой структурой
(Заметим в скобках, что лично я давно использую в качестве органайзера-на-все руки распрекрасный WikidPad)
[...]
Начну с реальной истории. В фирме, в которой я сейчас работаю, параллельно ведётся большое количество разных проектов, но с использованием аналогичных средств и систем. Со временем выяснилось что постоянно возникают ситуации, когда один разработчик пытается решить проблему, которую в другом проекте и в другое время уже благополучно решил другой. То есть попросту говоря отсутствует необходимая коммуникация, а по научному область эта называется кажется управление знаниями (knowledge management).
[...]
BASIC principles (найдено на LtU)
Вроде бы всем понятные вещи, но лучше, когда это высказано явно — Принципы, на которых основывается язык BASIC (точнне — VB.Net):
* Доступность (похожесть на англоязычный текст)
* Простота
* Гибкость
* Прагматизм
* Поддержка платформы .Net
ЗХ>Пара статей на Lifehacker.com (вообще весьма достойное чтиво): ЗХ>1. Geek to Live: List your life in .txt ЗХ>Предлагается структура для использования обычного txt-файла в качестве планировщика и todo-листа ЗХ>2. Geek to Live: Script your life in .txt ЗХ>Предлагается набор bash-скриптов для управления этой структурой
ЗХ>(Заметим в скобках, что лично я давно использую в качестве органайзера-на-все руки распрекрасный WikidPad)
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Попробуем такой формат. Не понравится — вешайте бомбы.
ЗХ>
ЗХ>Мартин Фаулер опубликовал статью под названием
Верней сказать, Фаулер опубликовал новую версию своей старой статьи.
ЗХ>Continous Integration
[skiped] ЗХ>[q] ЗХ>"Непрерывная интеграция" — практика разработки программ, при которой члены
.... ЗХ>Перевод мой,
Сорри, но переводить "Continous Integration" как "Непрерывная интергация" все равно что переводить Google как Гугл.
Здравствуйте, Dr.Gigabit, Вы писали:
ЗХ>>"Непрерывная интеграция" — практика разработки программ, при которой члены ЗХ>>Перевод мой, DG>Сорри, но переводить "Continous Integration" как "Непрерывная интергация" все равно что переводить Google как Гугл.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Здравствуйте, Dr.Gigabit, Вы писали:
ЗХ>>>"Непрерывная интеграция" — практика разработки программ, при которой члены ЗХ>>>Перевод мой, DG>>Сорри, но переводить "Continous Integration" как "Непрерывная интергация" все равно что переводить Google как Гугл.
ЗХ>Пардон, а как правильно?
Здравствуйте, Dr.Gigabit, Вы писали:
DG>Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>Здравствуйте, Dr.Gigabit, Вы писали:
ЗХ>>>>"Непрерывная интеграция" — практика разработки программ, при которой члены ЗХ>>>>Перевод мой, DG>>>Сорри, но переводить "Continous Integration" как "Непрерывная интергация" все равно что переводить Google как Гугл.
ЗХ>>Пардон, а как правильно?
DG>Думаю, лучше не пытаться
То есть в тексте нужно оставлять Continous Integration? Бррррр...
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Здравствуйте, Dr.Gigabit, Вы писали:
DG>>Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>>Здравствуйте, Dr.Gigabit, Вы писали:
ЗХ>>>>>"Непрерывная интеграция" — практика разработки программ, при которой члены ЗХ>>>>>Перевод мой, DG>>>>Сорри, но переводить "Continous Integration" как "Непрерывная интергация" все равно что переводить Google как Гугл.
ЗХ>>>Пардон, а как правильно?
DG>>Думаю, лучше не пытаться
ЗХ>То есть в тексте нужно оставлять Continous Integration? Бррррр...
Why not? Уж больно слух режет. Думаю, можно привести много примеров, достаточно посмотреть названия некоторых соседних разделов форума
Здравствуйте, Dr.Gigabit, Вы писали:
DG>Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>Здравствуйте, Dr.Gigabit, Вы писали:
DG>>>Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>>>>Здравствуйте, Dr.Gigabit, Вы писали:
ЗХ>>>>>>"Непрерывная интеграция" — практика разработки программ, при которой члены ЗХ>>>>>>Перевод мой, DG>>>>>Сорри, но переводить "Continous Integration" как "Непрерывная интергация" все равно что переводить Google как Гугл.
ЗХ>>>>Пардон, а как правильно?
DG>>>Думаю, лучше не пытаться
ЗХ>>То есть в тексте нужно оставлять Continous Integration? Бррррр...
DG>Why not? Уж больно слух режет. Думаю, можно привести много примеров, достаточно посмотреть названия некоторых соседних разделов форума
Не понимаю
Слово "непрерывная" режет слух? "Интеграция"? Несоответствие смысла? Неестественность для русского языка? Не понимаю, ей-бо. Зачем общаться по-англо-русски, если можно по-русски?
(Промежду прочим, на мой вкус "каркас" лучше "фреймворка" (и уж точно лучше "инфраструктуры"), а "переработка/переделка" лучше "рефакторинга".)
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>Здравствуйте, Dr.Gigabit, Вы писали:
[skiped]
ЗХ>>>То есть в тексте нужно оставлять Continous Integration? Бррррр...
DG>>Why not? Уж больно слух режет. Думаю, можно привести много примеров, достаточно посмотреть названия некоторых соседних разделов форума
ЗХ>Не понимаю ЗХ>Слово "непрерывная" режет слух? "Интеграция"? Несоответствие смысла? Неестественность для русского языка? Не понимаю, ей-бо. Зачем общаться по-англо-русски, если можно по-русски?
ОК, давайте по-русски
ЗХ>(Промежду прочим, на мой вкус "каркас" лучше "фреймворка" (и уж точно лучше "инфраструктуры"), а "переработка/переделка" лучше "рефакторинга".)
Весьма спорный вопрос. Только, пожалуй, эта тема отдельного разговора. К сожалению, большинство технических понятий и терминов — заимствованы, а адаптируют их к русскому кому как больше нравится В этом и проблема.
Здравствуйте, Зверёк Харьковский, Вы писали:
ЗХ>(Промежду прочим, на мой вкус "каркас" лучше "фреймворка" (и уж точно лучше "инфраструктуры"), а "переработка/переделка" лучше "рефакторинга".)
не согласен с выделеным. уже наоброт когда говорят переработка — режет слух, ибо все таки рефакторинг движется чуть ли ни в направлении создания нового направления в разработке и это уже не чистая переработка. ИМХО.
Здравствуйте, ironwit, Вы писали:
ЗХ>>(Промежду прочим, на мой вкус "каркас" лучше "фреймворка" (и уж точно лучше "инфраструктуры"), а "переработка/переделка" лучше "рефакторинга".)
I>не согласен с выделеным. уже наоброт когда говорят переработка — режет слух, ибо все таки рефакторинг движется чуть ли ни в направлении создания нового направления в разработке и это уже не чистая переработка. ИМХО.
Ну да, это стандартная "отмазка" переводчиков: "мы оставляем транслитерацию, потому что это новое понятие и бла-бла". Но следует учесть, что в английском языке "refactoring" хотя и является неологизмом, но с вполне очевидной этимологией и породившим целое словарное гнездо (глагол "to refactor", причастие "refactored"). Русский язык, к сожалению, несколько менее гибок (к тому же, идеально точный по словообразованию перевод "перепроизводство" уже занят под иное значение); слова "рефакторить, рефакторенный, порефакторить" до сих пор являются сленговыми, а специальная литература пестрит жуткими канцеляризмами "делать рефакторинг, заниматься рефакторингом; код, полученный в результате рефакторинга" и т.п. Впрочем, даже если бы словарное гнездо образовалось, все равно остается проблема "инородности" слова, хотя в рамках XP (где эта практика возникла) принято называть практики простыми, разговорными и всем понятными словами.
ЗЫ: есть такая практика в XP под названием "drive a spike" — буквально "сколотить на гвоздях", означает быструю проверку малознакомой технологии путем написания некоторого количества кода. Русским переводчикам очень нравится переводить ее как ... "drive a spike". Это стремление к "академичному" переводу технической литературы, написанной живым разговорным языком — приводит к тому, что бОльшую часть современной англоязычной литературы можно читать ТОЛЬКО в оригинале.
quicksort =: (($:@(<#[),(=#[),$:@(>#[)) ({~ ?@#)) ^: (1<#)
