Еще один маленький скриптик

Вот еще маленький скриптик, который из видео файла делает MOV для iTunes. Он не переконвечивает видео, просто подменяет контейнер, по этому перегон фильма занимает несколько минут.
продолжение...

AudioBook mp3 to iPod

Навалял маленький скриптик, который из mp3 делает аудио книги в формате iPod. Юзает ffmpeg. Может пригодится кому.
продолжение...

Мифы о ГЛОНАСС.

Мифы о ГЛОНАСС. Часть 2: оно нам надо?

NFS Server на Solaris 10

Просто что бы не забыть.

enable-м сервер: svcadm -v enable -r network/nfs/server
временная шара: share -F nfs -o rw /path/to/public
что бы шара работала после перезагрузки, добовляем в /etc/dfs/dfstab share -F nfs -o rw /path/to/public
продолжение...

Мифы о ГЛОНАСС.

Мифы о ГЛОНАСС. Часть 1: зачем это всё?

Как удалить все данные пользователя в oracle

17:30 17.03.2009
Как удалить все данные пользователя в oracle
SET NEWPAGE 0

SET SPACE 0

SET LINESIZE 80

SET PAGESIZE 0

SET ECHO OFF

SET FEEDBACK OFF

SET HEADING OFF

SET MARKUP HTML OFF

SET ESCAPE \

SPOOL delme.sql

select 'drop '||object_type||' '|| object_name|| DECODE(OBJECT_TYPE,'TABLE',' CASCADE CONSTRAINTS;',';') from user_objects;
SPOOL OFF

@delme.sql

Эээх, жаль сегодня будет такой красивый uptime гробить :(
продолжение...

Создание ISO-образа в Mac OS X

Доступен GWT 1.5
Почитать можно Тут
Свои прожекты частично пересобрал под него, вроде работает.
продолжение...

Случайно наткнулся на свою старенькую статейку, написанную еще в 2004-м году.
Hастpойка GPRS Internet в eComStation 1.1


Итак, использовалась тpyба Motorola c350l, кабель usb2miniUsb, eComStation 1.1, InJoy. Долгие поиски пpовода типа usb2serial плодов не дали. Hе знаю сyществyют ли они в пpиpоде вообще. Зато после долгих pасспpосов и поисков наткнyлся на дpайвеp usbcom.sys. В eCS 1.1, не знаю как в дpyгих системах, этот дpайвеp весьма глючил, пpи появлении тpyбы на пpоводе система падала с непонятным exception. Hо нашелся фикс - warpupdates.

Дальше в config.sys пpописал:

BASEDEV=USBD.SYS
BASEDEV=USBUHCD.SYS
BASEDEV=USBHID.SYS
DEVICE=C:\OS2\BOOT\USBCOM.SYS /N:COM3
Это было сделано по pекомендациям из \OS2\BOOT\USBBASIC.TXT а так как y меня нет юсбишных мышей, пpинтеpов и сидюков, поэтомy все это выкинyл из конфига. Дальше pебyт. Все тепеpь настpаиваем InJoy, или какyю-то дpyгyю звонилкy, мне лично нpавится InJoy.

New->Configuration name->NCC
User ID->ncc
Password->ncc
Comm setup
Port setup->COM3
Port speed->115200
Phone number #1->*99***1#
Modem initstring #1->AT&F
Modem initstring #2->AT+CGDCONT=1,"IP","internet"
Замечание: User ID, Password, Phone number, Modem initstring #2 Я полyчил от своего опеpатоpа мобильной связи: HСС "Hижегоpодская сотовая связь"

29.04.2004
продолжение...

Компания Yahoo утверждает, что ей удалось побить мировой рекорд, создав самую большую и нагруженную базу данных в мире!

Объём запущенной год назад базы данных достиг 2 петабайт. Система создана для аналитических целей, в ней хранится история поведения веб-пользователей (утверждается, что в месяц сохраняются данные о полумиллиарде пользователей). Помимо прочего, интернет-гигант заявляет, что это не только самая большая БД в мире, но ещё и самая нагруженная — в сутки в ней регистрируются данные о 24 млрд событиях.

А теперь самое интересное. Управляет этим монстром модифицированный PostgreSQL.



Это — результат покупки компании-стартапа Mahat Technologies, изначально работающей с самой развитой СУБД с открытым исходным кодом PostgreSQL. Код «Постгреса» был модифицирован для работы с такими огромными объёмами информации (одно из самых крупных изменений: ориентация на по-колоночное хранение вместо традиционного построчного, что замедляет запись на диск, но обеспечивает лучшую скорость доступа к данным для аналитических целей). Положительный результат налицо: некоторые таблицы в базе содержат триллионы строк, которые не просто лежат мёртвым грузом на дисках, но могут быть запрошены и обработаны стандартным SQL, в стандартной ACID-совместимой среде.

Инженеры Yahoo ожидают рост до 5 петабайт к следующему году. И они готовы к такому росту. Для сравнения: редко встречаются БД уровня предприятия объёмом более десятков терабайт. Например, одна из самых больших публично известных БД в мире — база данных налоговой службы США «весит» всего лишь 150 терабайт. Компания Ebay заявляет, что работает с системами, обрабатывающими 10 млрд строк в сутки, при этом суммарный объём данных в этих системах составляет 6 петабайт, а объём данных у самой большой из систем — около 1.4 петабайт.

Стоит понимать, что речь идёт именно о СУБД и БД, построенных на них. Есть хранилища данных с ещё более впечатляющим объёмами, но при этом данные в них практически недоступны для анализа и обработки. К примеру, Всемирный центр данных о климате в Гамбурге обладает хранилищем в более чем 6 петабайт данных, сохранённых на магнитной ленте, при этом в «активном» состоянии находятся «лишь» 220 терабайт данных (которые обслуживаются СУБД под управлением Linux, см. PDF).

«PostgreSQL продолжает активно развиваться, подтверждая звание самой развитой СУБД из открытых, — комментирует представитель компании «Постгресмен» Николай Самохвалов. — В прошлом году инженеры Sun показали всему миру, что PostgreSQL не уступает в производительности Oracle. На недавно прошедшей в Канаде международной конференции PGCon2008 представители NASA рассказали о своём опыте использования PostgreSQL для работы с большими базами данных из области наблюдения за климатом. Опыт Yahoo — очередное яркое подтверждение зрелости PostgreSQL. И это очень приятная новость для всех нас, жаль лишь, что, насколько я знаю, Yahoo пока не планирует делиться своими наработками с сообществом.»

отсюда
продолжение...

Дело Ханса Рейзера: Гений Linux обвиняется в убийстве своей русской жены
продолжение...

Автор "Искусства программирования", известный математик Дональд Кнут в беседе с аналитиком Эндрю Бинстоком рассказывает о новых томах своей популярной книги, а также о преимуществах "открытого кода", о проблемах разработчиков с многоядерными компьютерами и о разнице между "грамотным" и "экстремальным" программированием. "Вебпланета" публикует сокращенный перевод этого интервью, появившегося в журнале InformIT. </em></p>

Эндрю Бинсток: Вы являетесь одним из отцов революции open-source, хотя широкая общественность не знает об этом. Но именно вы в свое время заявили, что выпустили TeX с открытым кодом из-за проблем, которые создают проприетарные приложения, а также для того, чтобы код могли модифицировать другие люди. Оба этих положения сейчас являются ключевыми идеями проектов с открытым кодом. Насколько вас впечатляют нынешние успехи данной идеологии?

Дональд Кнут: Успех открытых кодов - пожалуй, единственная вещь в компьютерной сфере, которая не удивляла меня за прошедшие десятилетия. Однако эта идеология до сих пор не раскрыла полностью свой потенциал. Я верю, что программы с открытым кодом будут все больше доминировать в результате того, что цифровая экономика все больше будет сдвигаться от продуктов к сервисам, и будет появляться все больше добровольцев, готовых улучшать программы.

К примеру, программа с открытым кодом может порождать тысячи бинарных вариаций, которые точно настроены на конфигурации компьютеров отдельных пользователей, в то время как коммерческий софт обычно существует всего в нескольких версиях. Оригинальный исполняемый файл должен включать разные штуки вроде неэффективных sync-инструкций, которые совершенно неподходят для многих инсталляций; все эти ненужные вещи уходят, когда исходник можно модифицировать. Это большое преимущество открытых кодов.

Тем не менее, я думаю, что некоторые программы, такие как Adobe Photoshop, всегда будут побеждать конкурентов типа Gimp - и точной причины этого я даже не знаю! Но я действительно готов платить хорошие деньги за хороший софт, если я уверен, что его сделали лучшие программисты.

Помните, однако, что мое мнение по экономическим вопросам очень сомнительно, потому что я всего лишь ученый и преподаватель. Я почти ничего не понимаю в рынке.

Э.Б.: Говорят, вы однажды участвовали в программерском конкурсе в Стенфорде, и ваша победившая программа работала корректно после одной-единственной компиляции. Это правда? Я к тому, что современные разработчики часто создают программы, дописывая небольшие расширения к коду, затем тут же их компилируют и тестируют "частями" (unit tests). Что вы думаете о подобном подходе к разработке?

Д.К.: История, которую вы упомянули - типичная легенда, и правды в ней мало. Вот что было на самом деле: Джон Маккарти в 1971 году решил провести конкурс Memorial Day Programming Race. Все участники конкурса, кроме меня, работали в AI Lab на холмах близ Стенфорда, используя систему разделения машинного времени WAITS. Я же находился внизу, в главном кампусе, и мне был доступен только один общий компьютер, в который надо было вставлять карточки и ждать своего процессорного времени для их обработки в общем потоке. Я писал на виртовском языке ALGOL W (предшественник "Паскаля"). Моя программа не сработала с первого раза, однако я использовал офлайновый дебаггер Эда Саттерсвейта для этого языка, так что мне понадобилось всего два прогона. В то же время ребята, которые использовали систему WAITS, не смогли получить достаточного машинного времени, потому что их машина была перегружена. Человек, занявший второе место, который использовал этот "современный" подход, пришел с результатом примерно через час после того, как я сдал свою работающую программу, отлаженную "стариковским" методом. Короче, это был нечестный конкурс.

Что касается второй части вопроса - идею немедленной компиляции и "тестов частями" я использую редко, когда ищу дорогу в совершенно неизвестной среде и мне очень нужна обратная связь о том, что работает, а что нет. В противном случае, куча времени тратится на деятельность, которая не нужна и о которой я даже не думаю. Мне нет особой нужды "импровизировать".

Э.Б.: Одна из новых проблем для разработчиков, особеннно разработчиков клиентских приложений - необходимость изменить свое мышление для того, чтобы писать программы в терминах потоков (threads). Эта концепция, появившаяся вместе с недорогими многоядерными компьютерами, очевидно потребует переработки многих алгоритмов под многопоточный режим работы. Между тем, в 4-м томе вашего "Искусства программирования" эта проблема, кажется, не рассматривается всерьез. Собираетесь ли вы в будущем отдельно заняться темой многопоточных и параллельных вычислений в новых книгах - особенно с учетом того, что это хорошо сочеталось бы с комбинаторными темами, над которыми вы в последнее время работаете?

Д.К.: Сфера комбинаторных алгоритмов настолько глубока, что я буду счастлив, если удасться уложить в три-четыре тома хотя бы то, что касается методов последовательных вычислений. И я не думаю, что последовательные алгоритмы когда-либо станут "несущественными".

С другой стороны, "период полураспада" параллельных методов очень короткий, потому что "железо" меняется очень быстро, и каждая новая машина требует иного подхода. И я давно уже решил, что буду придерживаться той области, которую знаю лучше всего. Есть люди, которые гораздо лучше меня разбираются в параллельных вычислительных машинах; чтобы понять, как работать с этой "одновременностью", программисты должны слушать таких людей, а не меня.

Э.Б.: Между тем, производители многоядерных машин сейчас расстраиваются по поводу того, как трудно привлечь разработчиков к этим машинам. Как бывший университетский профессор, что вы думаете об этом? Может, проблема в инструментах - например, необходима более естественная поддержка одновременных вычислений в языках программирования? Или проблема в самих вычислительных архитекрутах? Или какие-то другие решения возможны?

Д.К.: Мне придется несколько уклониться от прямого ответа, и побурчать о моих личных сомнениях по поводу нынешнего тренда в сторону мультипроцессорных архитектур. Мне кажется, у создателей "железа" кончились идеи, и они пытаются свалить на программистов всю вину за грядущий облом Закона Мура. Они дают нам машины, которые работают быстро - но лишь по немногим ключевым показателям! Я не удивлюсь, если вся идея многопоточных вычислений окажется лажей. И это будет даже более серьезное фиаско, чем хваленый подход Itanium - который обещал работать просто удивительно, но потом оказалось, что для него невозможно написать желаемых компиляторов.

Давайте я так скажу: за прошедние 50 лет я написал более тысячи программ, и большинство из них довольно серьезного размера. Но при этом я не могу назвать даже пять из этих программ, исполнение которых значительно улучшилось благодаря параллелизму или многопоточной обработке. К примеру, многопроцессорность совершенно не улучшает работу редактора TeX.

Много ли вы знаете программистов, которые с энтузиазмом относятся к этим обещанным машинам будущего? Кроме печали, я ничего не слышу на эту тему от специалистов по софту - хотя "железячники" говорят, что я неправ.

Я знаю, что параллельные вычисления важны для рендеринга графики, взлома кодов, сканирования изображений, моделирования физических и биологических процессов, и так делее. Но все эти приложения требуют специально заточенного кода и специфических алгоритмов, которые необходимо менять каждые несколько лет. Если бы я знал достаточно о таких методах, чтобы написать о них в "Искусстве программирования", мое время все равно было бы потрачено напрасно, поскольку вскоре читать эти главы было бы уже бесполезно. Аналогичным образом, когда я готовил третье издание третьего тома, я выбросил большую часть материала о сортировках на магнитных лентах. Эта тема когда-то была одной из самых горячих в программировании, но теперь эта часть книги - бесполезный перевод бумаги.

В компьютере, который я использую сейчас, два процессора. Я использую оба, когда делаю две независимые работы в одно и то же время. Это замечательно, но это занимает всего несколько минут в неделю. Если бы у меня было четыре процессора, или восемь, или больше, я все равно бы не мог работать лучше - с учетом, конечно, специфики моей работы - хотя я почти ежедневно использую компьютер в течение целого дня. Так какая мне радость о того параллельного будущего, которое обещают производители железа? Они думают, какая-то волшебная пуля заставит все эти мультипроцессоры ускорить мою работу; я же думаю, что это вылет в трубу... хотя нет, это плохая метафора! "Трубопроводы" (pipelines) прекрасно работают на меня, а вот "потоки" (threads) не работают. Наверное, лучше сказать "пузырь".

С другой стороны, я признаю, что веб-браузинг может стать лучше с мульти-ядрами. Я, однако, говорю здесь о моей работе, а не о развлечениях. Я также должен признать, что у меня нет особо гениальных идей насчет того, чего бы я хотел от создателей "железа" вместо многопроцессорности - чтобы они бросились долбить стену с уважением к последовательным вычислениям. Хотя в моем дизайне компьютера MMIX имеется ряд идей, способных существенно улучшить исполнение программ, которые меня больше всего интересуют - ценой за это является несовместимость со старыми программами для x86-машин.

Э.Б.: Один из ваших проектов, который пока не привлек широкого внимания - это "грамотное программирование" (literate programming - по смыслу точнее было бы перевести как "литературное программирование", но мы оставим буквальный перевод, который встречается чаще - прим. Вебпланеты). Как вы думаете, почему этот проект "не зажигает"? И если оглянуться назад - может быть, стоило сделать это как-то иначе?

Д.К.: Грамотное программирование - это очень персональная вещь. Я люблю этот проект - но возможно, это потому, что я очень странный человек. У проекта тысячи фанатов, но не миллионы.

По моему опыту, софт, созданный с использованием грамотного программирования, оказывается значительно лучше, чем тот, что создается традиционными способами. Тем не менее, обычный софт тоже зачастую не так плох - я бы поставил ему "тройку", а не "кол". Именно поэтому традиционные методы остаются в ходу. И поскольку эти методы понятны огромному числу программистов, у большинства из них нет стимула меняться. Точно так же, как я не мотивирован учить язык эсперанто, хотя это могло быть более полезно, чем английский, немецкий, французский и русский.

Джон Бентли, возможно, был прав, когда отвечал на вопрос, почему грамотное программирование не захватило весь мир. Он сказал, что очень малый процент людей в мире хорошо программируют, и очень малый процент - умеют хорошо писать документацию; а я еще требую от людей, чтобы они попали сразу в обе эти группы.

Что до меня самого, грамотное программирование определенно является самой важной вещью, которая вышла из моего проекта TeX. Это не только помогло мне писать программы быстрее и надежнее, но и оказалось одним из главных источников удовольствия с 80-х годов. Некоторые из моих главных программ, такие как мета-симулятор для MMIX, просто не могли быть написаны с какой-либо другой методологией программирования. Сложность программы была слишком высока для того, чтобы с ней справился мой ограниченный мозг; без грамотного программирования вся затея бы рухнула.

И если люди найдут какие-то красивые пути использования новомодных мультипоточных машин, я полагаю, что такое открытие сделают именно те, кто использует грамотное программирование. Это способ подняться выше стандартного уровня достижений. Но я не верю, что такие идеи имеет смысл кому-то навязывать. Если грамотное программирование - не ваш стиль, просто забудьте его и делайте то, что вам нравится. А если оно не понравится никому, кроме меня - пусть оно умрет.

Но есть и позитивные новости: я был рад обнаружить, что мои правила для системы грамотного программирования CWEB уже стали стандартом в пре-инсталлируемом софте типа Makefiles.

Э.Б.: Несмотря на то, что редактор TeX написан много лет назад, он до сих пор процветает, в основном как платформа для LaTeX. И хотя код TeX'а был "заморожен" по вашей просьбе - какие вещи вы хотели бы поменять в нем, если бы у вас было время и ресурсы?

Д.К.: Я думаю, изменения в TeX вызвали бы больше вреда, чем пользы. Люди, которым нужны другие фичи, создают свои собственные системы, и я всегда поддерживал такое развитие - только пусть не дают своим программам то же название, что у моей. Я хочу сам отвечать за TeX и Metafont, и за все те вещи, которые с этой моей работой связаны - например, точные размеры символов в шрифтах Computer Modern.

Э.Б.: Еще один редко обсуждаемый вопрос в области разработки софта: как заниматься дизайном программы в совершенно новой области? Вы столкнулись с этим, когда взялись за TeX: никакие объекты цифрового искусства не были тогда доступны в виде открытого кода, и это была совершенно новая область, в которой вы не были экспертом. Как вы занимались дизайном, и как много времени прошло, пока вы смогли почувстовать себя комфортно в работе над этой программой?

Д.К.: Хороший вопрос! Я дал детальный ответ в 10-й главе книги "Грамотное программирование" (Literate Programming), а также в 1-й и 2-й части книги "Цифровая типография" (Digital Typography). Я думаю, все, кому интересна эта тема, с удовольствием прочтут эти материалы.

Э.Б.: Книга про TeX и сама программа показывают, что вы очень заботились об ограничениях памяти - это было серьезной проблемой в то время. Сейчас забота о памяти в основном связана с параметрами кэш-памяти. Очевидно, что использование кэш-дружественных алгоритмов не могло пройти мимо вашего "радара". Планируете ли вы осветить в новой книге роль кэша в разработке алгоритмов?

Д.К.: Уже упомянутый компьютер MMIX является тестовой площадкой для различных кэшей. И поскольку эта программно-настраиваемая машина, мы можем выполнять эксперименты, которые можно будет воспроизвести хоть через сто лет. Конечно, в следущем издании 1-3 томов "Искусства программирования" будет обсуждаться работа базовых алгоритмов с учетом разных параметров кэш-памяти. В 4 томе также есть дюжина упоминаний кэш-памяти и кэш-дружественных техник.

Э.Б.: Какие инструменты вы используете сейчас, когда пишете новые главы "Искусства программирования"? Используете TeX, LaTeX, CWEB? Другие редакторы? И что вы используете сейчас для программирования?

Д.К.: Мой основной стиль работы - сначала все записывать карандашом на бумаге, сидя перед большой мусорной корзиной. Затем я использую Emacs для набора текста, применяя инструкции для TeX. Я использую tex, dvips, и gv, чтобы смотреть результаты. Математические формулы проверяю через Mathematica.

Алгоритмы я кодирую в CWEB, который отлично работает с дебаггером GDB. Иллюстрации делаю в MetaPost (или, в редких случаях, на "Маке" с использованием Adobe Photoshop or Illustrator). У меня есть несколько самодельных инструментов, как например своя программа проверки орфографии для TeX и CWEB внутри Emacs. Я создал собственный шрифт для Emacs, потому что мне очень не нравится, как апостроф и левая открывающая кавычка в ASCII-коде превращаются в независимые символы, которые визуально не соответствуют друг другу. У меня есть также специальные режимы для Emacs, которые помогают классифицировать десятки тысяч статей и заметок в моих файлах, и специальные настройки клавишных комбинаций быстрого вызова, что делает написание книг похожим на игру на органе. Для ввода команд с терминала я предпочитаю эмулятор rxvt вместо xterm. С прошлого декабря я использую программу бэкапа под названием backupfs, которая прекрасно удовлетворяет мою потребность архивировать ежедневное состояние каждого файла.

Согласно текущему состоянию папок в моем компьютере, я в этом году написал 68 программ в CWEB. Около 100 было в 2007-м, 90 в 2006-м, 100 в 2005-м, 90 в 2004-м, и так далее. В CWEB очень удобная система изменения файлов, которая позволяет мне быстро создавать множественные версии и вариации на тему; так, в 2008-м я сделал 73 варианта тех самых 68 программ. Можете теперь понять, насколько важно в моей жизни "грамотное программирование".

Я использую сейчас Ubuntu Linux на отдельном лаптопе - у него нет подключения к Интернету. Я время от времени перетаскиваю файлы на флешках с этого даптопа на "Маки", которые использую для веб-серфинга и работы с графикой; но мои "фамильные бриллианты" я доверяю только "Линуксу". Кстати, с "Линуксом" я предпочитаю классический оконный менеджер FVWM, а не модные среды GNOME and KDE, которые нравятся другим.

Э.Б.: В предисловии к нулевой части 4 тома "Искусства программирования" вы пишете, что этот том будет состоять из трех или более книг. Кажется, вам действительно нравится писать такие книги. Насколько верным является обещание на вашем сайте, что 5-й том увидит свет к 2015 году?

Д.К.: Если вы посмотрите через Wayback Machine на прошлые инкарнации этого сайта, то увидите, что дата 2015 не была постоянной. Вы правы, мне нравится работать над этим материалом, потому что я постоянно натыкаюсь на интересные факты, которые просто нельзя игнорировать - хотя более половины моих заметок все равно не достигают финального варианта книги.

Точное время выхода нового тома сказать невозможно, ведь пока я не погрузился в каждую секцию, я даже не знаю, какие из моих материалов будут фундаментальными, а какие окажутся несущественными или наооборот, слишком продвинутыми. Множество современных книг на эти темы являются попыткой заявить свое академическое преимущество, которое мне мало интересно; сейчас авторы частенько описывают всякие "тайные техники", которые могут победить более простые лишь тогда, когда размер проблемы превышает число протонов во Вселенной. Такие алгоритмы никогда не будут нужны в реальных компьютерных приложениях. Я читаю сотни таких работ, чтобы поглядеть, нет ли там каких-нибудь ноу-хау для программистов - но в большинстве случаев приговор ясен сразу.

Э.Б.: В конце 2006 года у вас диагностировали рак простаты. Как ваше здоровье сейчас?

Д.К.: Точно, рак будет серьезной проблемой. Но у меня хорошие доктора. Сейчас я чувствую себя таким же здоровым, как всегда - со скидкой на то, что мне 70 лет. Слова бегут легко, когда я пишу "Искусство программирования" и программы для этого проекта. Я просыпаюсь по утрам с идеями, которые мне нравятся, и некоторые из этих идей нравятся мне даже потом, когда днем я записываю их на компьютере.

С другой стороны, я легко отдаю себя в руки Господа с уважением к тому, как много я еще смогу сделать перед тем, как рак или сердечный приступ или старость меня доканают. И даже если я скоропостижно скончаюсь завтра, у меня нет причин жаловаться, поскольку моя жизнь была невероятно счастливой. Тем не менее, пока я могу писать на темы программирования, я надеюсь сделать все возможное, чтобы организовать и резюмировать десятки тысяч документов и заметок, которые я собирал с 1962 года.

Э.Б.: Peoples Archive недавно сделал ряд видео-интервью, в которых вы рассказывате о своем прошлом. В ролике под названием "Совет молодым людям" вы советуете им не делать что-то только потому, что это популярно. Как мы все хорошо знаем, в разработке программного обеспечения тоже часто случаются "модные увлечения". Могли бы вы привести пример таких сомнительных идей, которые разработчикам не стоит применять только потому, что они популярны, или потому, что так сейчас делают все?

Д.К.: Хмм... Вопрос противоречивый, потому я обычно советую молодым людям слушать себя больше, чем других - а я сам как раз и есть один из "других". Любая биография человека, которого вы захотите использовать в качестве ролевой модели, покажет вам, что он или она делали множество вещей, противоречащих "здравому смыслу" своего времени.

Однако я не буду уколоняться от этого вопроса, хотя и не люблю обижать чужие чувства - ведь надо понимать, что методология программирования сродни религии. Но даже с учетом того, что нет никаких причин слепо верить мнению программиста и математика вроде меня, я все-таки скажу, что все вещи, которые я слышал о так называемом "экстремальном программировании" (extreme programming), кажутся мне совершенно неправильной дорогой... с одним исключением. Исключение касается работы в команде и чтения кодов друг друга. Эта идея верная, и она даже может затмить все другие ужасные аспекты экстремального программирования, которые меня беспокоят.

Я также должен признать, что у меня есть сильное предубеждение против моды на многоразовое использование одних и тех же кодов (reusable code). Для меня, "пере-редактированный" код гораздо лучше, чем нетронутый "черный ящик" или набор инструментов. Я об этом много могу говорить. Если вы убеждены, что повторно исползуемый код прекрасен, я вряд ли смогу вас разубедить. Но вы никогда не разубедите меня, что такой код не опасен.

Еще одна вещь, о которой вы, возможно, хотели спросить: почему новая книга в серии "Искусство программирования" называется Том 4 Часть 0, а не Том 4 Часть 1? Ответ, который поймут все программисты, состоит в том, что я не был готов начать Том 4 с "самого начала" - точно так же, как инициализация программы не может быть написана до того, как сама программа примет определенную форму. Поэтому я начал в 2005 году со второй части 4 тома, затем пошли третья и четвертая часть (вспомните о "Звездных войнах", которые начались с Эпизода 4).

Это позволило мне собраться с духом для написания первой части книги. Но тогда я понял, что вводные главы должны включать гораздо больше материала, чем вместится в одну книжку. Таким образом, вспомнив предложение Дейкстры о том, что счет должен начинаться с нуля, я решил сначала выпустить Том 4 Часть 0. Ждите также Часть 1 в этом году!

Источник
продолжение...

С днем рождения, Apple [Computer]!

С днем рождения, Apple [Computer]!

Когда Стив Возняк закончил конструировать компьютер Apple I, схемы и планы машины он хотел раздать бесплатно. Однако тут вмешался Стив Джобс, который убедил Воза в том, что гораздо целесообразнее эти схемы кому-нибудь продать. Под этим "кем-нибудь" подразумевались либо Atari, где работал Джобс, либо Hewlett-Packard, где трудился Воз. Каково же было их разочарование, когда обе компании отказались от столь "заманчивого" предложения.

Это заставило компаньонов искать альтернативу, которая и была найдена. Было решено основать свою собственную компанию. Это решение повлекло за собой такую проблему, как поиск начального капитала. Для ее решения Джобс продал свой микроавтобус, а Воз - инженерный калькулятор. Это позволило набрать 1750 долларов (неплохие деньги для того времени) и "родить" компанию Apple Computer.

Однако тут встала другая проблема. Каждый из Стивов владел 50 процентами акций новой компании, а поэтому когда дело доходило до споров, то компромисса достичь было сложно - доля каждого в Apple была абсолютно одинакова. Нужен был кто-то третий, кто возьмет на себя роль "контрольного пакета акций". Им стал Рон Вейн, коллега Джобса по Atari. Ему вручили 10 процентов акций и обязали решать спорные вопросы. Стоит заметить, что именно Вейн разработал первый логотип Apple, который вскоре был отвергнут из-за своей излишней сложности.

Троица оформила бумаги на регистрацию Apple 1 апреля 1976 года. Так рождалась легенда, которой вот уже 32 года удается баламутить этот мир...
С днем рождения, Apple [Computer]!

Источник/Source: Deep Apple
продолжение...

Сборка package под FreeBSD. Управление пакетами.

09:47 09.07.2007
Сборка package под FreeBSD. Управление пакетами.

Сборка package под FreeBSD.

$ ./configure --help

$ ./configure --prefix=/usr/local

$ make all

$ mkdir /var/tmp/emacs_inst
$ make prefix=/var/tmp/emacs_inst

drwxr-xr-x   2 root  wheel       512 20 июн 13:01 bin
drwxr-xr-x   3 root  wheel       512 20 июн 13:01 libexec
drwxr-xr-x   5 root  wheel       512 20 июн 13:00 share
drwxr-xr-x   3 root  wheel       512 20 июн 13:01 var

@comment PKG_FORMAT_REVISION:1.1
@name emacs-22.1.50
@comment ORIGIN:editors/emacs
@cwd /usr/local
@srcdir /var/tmp/emacs_inst
share/emacs/22.1.50/etc/BABYL
share/emacs/22.1.50/etc/CENSORSHIP
share/emacs/22.1.50/etc/COOKIES
share/emacs/22.1.50/etc/COPYING
share/emacs/22.1.50/etc/DEBUG

$ mtree -cdin -k uname,gname,mode -p /var/tmp/emacs_inst >MTREE_DIRS

$ pkg_create -j -c +COMMENT -d +DESC -f +CONTENTS -m +MTREE_DIRS emacs-22.1.50

Браузер Netscape Communicator стал частью истории

Компания AOL сегодня сообщила о том, что с 1 февраля 2008 года окончательно прекращает дальнейшие разработки и техническую поддержку интернет-обозревателя Netscape Communicator. В компании сообщили, что обновлений для нового броузера уже не будет с 1 января 2008 года, а в том случае, если в броузере будут обнаружены ошибки и проблемы безопасности, то исправления будут выпускаться до 1 февраля.

Вcем пользователям это легендарного броузера в AOL смело порекомендовали переходить на Mozilla Firefox, так как считают его большее чем достойным аналогом. По словам директора подразделения Netscape Тома Драпо, компания AOL уделяла массу внимания и тратила множество сил и энергии на поддержку и разработку броузера более 10 лет, однако успех этой разработки в последние годы был значительно более скромным, нежели у Internet Explorer или Mozilla Firefox.

Также в AOL сообщили, что раздел на портале компании, посвященный броузеру сохранится.

Старшее поколение интернет-пользователей помнит, что первые бета-версии браузера, выпущенные в 1994 году, назывались Mosaic, а затем Mosaic Netscape, пока из-за Национального суперкомпьютерного центра (National Center for Supercomputing Applications, создателя NCSA Mosaic, в разработке которого участвовало много основателей Netscape, название программы не было изменено на Netscape Navigator. Компания-разработчик также сменила название с Mosaic Communications на Netscape Communications.

На момент создания браузер обладал самыми широкими возможностями, что обеспечило ему лидерство на рынке, несмотря на то, что он существовал тогда в виде бета-версии. После выпуска версии 1.0 доля на рынке продолжила стремительный рост. В версию 2.0 была встроена полнофункциональная программа для работы с электронной почтой. Netscape превратился из просто браузера в семейство программ для работы в Интернете. В течение этого периода сам браузер и семейство программ носили одно название — Netscape Navigator. В это время, AOL начала включать в своё программное обеспечение браузер Microsoft Internet Explorer.

Версия 3.0 была первой, которая смогла принять вызов Microsoft Internet Explorer 3.0. По оценкам многих специалистов, на тот момент Netscape 3.0 стал браузером номер один в мире. Данный релиз существовал также в версии Gold, содержащей WYSIWYG — HTML-редактор, который позже стал стандартной функцией Netscape Communicator. С выпуском Netscape 4 была решена проблема одинакового названия собственно браузера и всего семейства программ: семейство программ было переименовано в Netscape Communicator.

В январе 1998 года Netscape Communications объявила, что все будущие версии станут бесплатными и будут разрабатываться в рамках сообщества открытого исходного кода (Mozilla). Также был анонсирован Netscape Communicator версии 5.0.

Netscape приняла решение разрабатывать браузер в рамках проекта с открытым исходным кодом. Была создана неформальная группа Mozilla Organization, которая в основном финансировалась Netscape. Эта группа должна была координировать усилия по разработке Netscape 5, базировавшемся на исходном коде Communicator. Однако, устаревший код создавал большие проблемы и было принято решение написать программу заново. Новый исходный код был назван Mozilla, на основе которого с небольшими изменениями был создан Netscape 6.

Версия 7 стала называться просто Netscape, браузер в составе семейства программ сохранил своё название Netscape Navigator. В 2003 году AOL закрыла подразделение Netscape и уволила или назначила на другие должности всех сотрудников, работавших над проектом. Проект Mozilla.org, однако, продолжил своё развитие в качестве независимого Mozilla Foundation, приняв многих бывших сотрудников Netscape. AOL продолжила самостоятельную разработку Netscape, однако, поскольку команда разработчиков была распущена, улучшения были минимальны.

Netscape 8, выпущенный в 2005 году называется Netscape Browser. Он сделан на основе браузера Mozilla Firefoх. Последней версией браузера является 9.0 именуемая Netscape Navigator. Самый крупный последний релиз браузера состоялся 17 августа 2007 года.

отсюда
продолжение...

книжко-читалко

10 Myths About Open Source Software Answered

10 Myths About Open Source Software Answered

Recent debates about FLOSS continue to be focused on an all-or-nothing perception; that, for example, to introduce FLOSS in a company, a full software migration is required. This, and the fact that there is limited knowledge of FLOSS projects outside of a very widely known ones (like Linux, Apache, OpenOffice.org), has created the perception that most of FLOSS is designed and directed as a direct competitor of Microsoft's own products. The reality is that there is an enormous number of active projects in practically every field of IT, including business-specific ones like ERP systems, and most of these projects are cross-platform, and can be executed on Microsoft Windows, Apple's OSX (which is itself based on more than 300 open source projects) or Linux. (For an estimate of the size of the FLOSS project panorama, see Estimating the number of active and stable FLOSS projects).

This myth is based on a common perception that FLOSS is exclusively developed by volunteers in a non-coordinated or unstructured way. There are many errors in this view:

• The volunteer perception: While volunteer contributions are a significant part (and sometimes the majority) of large-scale projects, around 50% of developers have received a financial compensation for working on FLOSS projects, either directly paid to improve the projects or paid to support them. This has been shown in recent studies² and can be inferred directly by the fact that in the software industry at large, 68% of software products include directly FLOSS-derived code.

• Paid programmers are better: Even for the percentage of contributions that do come from volunteers, it is commonly perceived that those should be of inferior quality, as there is no financial incentive to produce quality software. This ignores the fact that intrinsic incentives are in many cases more effective than monetary compensation, and the fact that sometimes users are interested in improving the software that they are using³. This second effect, called user-driven innovation, has been shown in past research to be a significant force. For example, around 25% of innovations in fields like software security, printed circuit boards CAD systems, and library software were designed and introduced by advanced users. The same effect provides a fundamental design feedback, as a large project collects both good and bad experiences in using the software (for example, the Ubuntu Linux "Testimonial and Experiences page" that allows for a form of user-driven "steering" of the project and the identification of trouble points.

• There is no support: Most large scale project do have companies that provide paid-for support, in a way similar to that of proprietary software companies. The availability of the source code and the modification rights gives also the additional advantage that support can be obtained even for projects that are no longer active, in stark difference with proprietary software where no code escrow clause was included in the acquisition contract.

• FLOSS is inherently unreliable: Many believe that FLOSS is inherently of lesser quality when compared to proprietary software. The reality is that most FLOSS projects are controlled with at least a semi-strict structure, and only very modular projects are inherently "bazaar-style" and allow for large scale internal decoupling. In any case, the impact of FLOSS-style development has been assessed in several research papers, and for example in a software engineering article we found⁴:

  "The hypothesis that open-source software fosters more creativity is supported by our analysis. The growing rate, or the number of functions added, was greater in the open-source projects than in the closed-source projects. This indicates that the open-source approach may be able to provide more features over time than by using the closed-source approach. Practitioners interested in capturing market share by providing additional features should look to the open-source methodology as a method to achieve this. In terms of defects, our analysis finds that the changing rate or the functions modified as a percentage of the total functions is higher in open-source projects than in closed-source projects. This supports the hypothesis that defects may be found and fixed more quickly in open-source projects than in closed-source projects and may be an added benefit for using the open-source development model."

  This is consistent with results from vendors of software defect identification tools like Reasoning, that found that while the bug density ratio in initial project releases is on par with proprietary developments, it improves rapidly and for some projects defect densities have been found to be significantly lower than that of the average proprietary code. For example, Reasoning found in a study of MySQL:

  "At a defect density of 0.09 defects per KLOC, the version of MySQL we inspected has a defect density that is about six times lower than the average of comparable proprietary projects.”

  This was confirmed by other studies like the reports from Coverity.

The fact that FLOSS is overall reliable can be inferred by surveys like the already mentioned CIO Insight survey, where 79% of respondents answered positively to the question "My company's experience with open source products other than Linux has been so good we plan to expand their use".

This is the easiest myth to dispel: Apart from the large IT companies that are actively promoting Open Source software like IBM, HP, Sun, and Oracle, about 86% of Fortune 1000 companies are deploying or testing FLOSS, and a similar measure is found in Europe⁵. Of those, 35% or more are deploying more than 20% of their systems as FLOSS, and 11% of companies report more than 20% of their applications as being Open Source software. While usage in server-centric and IT infrastructure is more common, around 26% of large companies are mentioning the use of Linux on the desktop, and a much larger percentage are reporting the use of other FLOSS like OpenOffice.org and Firefox on Microsoft Windows desktops. A curious fact that is also evident from other surveys is that many companies and public administrations are not aware of their internal use of FLOSS, sometimes for simple ignorance of the licensing terms and sometimes because the product is offered or embedded in what seems a traditional proprietary offering (for example, many security and networking products use FLOSS internally).

There are several aspects to this myth:

• The GPL license is "viral": The most widely used license does have a specific clause that when a software product that is derived from GPL software code is redistributed, the entire product must be distributed under the same license. This has prompted some to claim that the "viral aspect of the G.P.L. poses a threat to the intellectual property of any organization making use of it". The reality is that for most scenarios, this clause simply provides a way to prevent appropriation of code without giving back contributions or credit, and this is also one of the reasons why many developers *prefer* the GPL to other licenses. Simple *use* of Open Source software in itself does not require any change to the license of internally developed software, and most companies routinely run proprietary software on top of GPL-licensed code like the Linux kernel.

• The Free Software community steals the intellectual property of other companies: This is the byproduct mainly of litigation by the SCO Group company that in 2003 claimed that IBM improperly included copyrighted material in the Linux kernel. In the original claim, it was alleged that IBM "put SCO’s confidential and proprietary information into Linux, the free operating system" and that within the kernel several million lines of code were taken from SCO's Unix source code. However, the public was not told where that allegedly infringing code was found, nor were requests from the community for that information answered. Now, four years later, no millions of lines of code have materialized in the litigation, and the court in August of 2007 found that the UNIX and Unixware copyrights SCO claimed to have obtained in 1995 in fact did not transfer to SCO from Novell. Even if the copyrights belonged to SCO, there are less than 300 lines of code at issue in that case in the end, and it's mostly standard interface code that many believe would be found to have no copyright protection no matter who owns it. That's 300 lines of code out of more than 6 million lines of code in the Linux kernel.

  Subsequently, Microsoft issued similar allegations, only regarding patents, with Microsoft's CEO Steve Ballmer claiming that Linux "uses our patented intellectual property". However, once again, no specificity was provided. (See also Craig Mundie, Microsoft's vice president, speech at New York University's Stern school of Business in 2001, where he said that releasing source code into the public domain is "unhealthy", causes security risks and "as history has shown, while this type of model may have a place, it isn't successful in building a mass market and making powerful, easy-to-use software broadly accessible to consumers". Bill Gates said that the GPL "makes it impossible for a commercial company to use any of that work or build on any of that work", and Steve Ballmer famously said: "Linux is a cancer that attaches itself in an intellectual property sense to everything it touches ... if you use any open-source software, you have to make the rest of your software open source".)

  The reality is that structured FLOSS projects do have a strict patch acceptance policy, and as an example the Eclipse project has a strict due diligence process, that covers external contributions, code rights assignments, code review and license compatibility. The Eclipse foundation also uses automated tools to check for code copying, keyword scanning for words with legal significance and a controlled release review prior to updating the code. Similar processes are in place in other FLOSS projects⁶

While FLOSS as a definition covers principally the licensing regime, by extension the "openness" of the code introduces the possibility of sharing development efforts among different groups, in a way similar to those of the early user groups of the sixties. In this sense, Eric Raymond introduced in his seminal paper "The Cathedral and the Bazaar" the concept of shared development, contrasting this "bazaar" style where every developer is free to choose on what part of the code to work, in contrast to the "cathedral" or formalized development approach that is rigid and structured.

While the concept took hold quickly, the reality is that collaboratively developed projects tend to be executed in a continuum between cathedral and bazaar. For example, for most projects there is a formal structure (with many sub-projects, more open to external contributions) while other are strictly formal (for example, projects that use FLOSS code for use in a certified environment like avionics or safety-critical systems). The important point raised by Raymond is the fact that both coding and ancillary activities like bug fixing and production of documentation can be shared in a large community, creating in a sense "virtual software houses" that in a voluntary way provide effort and resources. This helps also in the leverage of a large community of expert users, that can contribute back in a significant way, as shown in the articles from Von Hippel.

When such collaboration takes place, it may be not only in the form of source code, as for example⁷:

"In the year 2000, fifty outside contributors to Open Cascade provided various kinds of assistance: transferring software to other systems (IRIX 64 bits, Alpha OSF), correcting defects (memory leaks…) and translating the tutorial into Spanish, etc. Currently, there are seventy active contributors and the objective is to reach one hundred. These outside contributions are significant. Open Cascade estimates that they represent about 20% of the value of the software."

A similar view has been presented in a presentation by Aaron Seigo at the Akademy KDE conference in 2006, where he presented the areas where volunteers collectively contribute to KDE:

• Artwork
• Documentation
• Human-computer interaction
• Marketing
• Quality Assurance
• Software Development
• Translation

If overall software suitability to the task is considered, it is clear that non-code contributions are as important as source code; for example, translations, documentation and overall quality are vital for the software to be adopted by end-users worldwide.

This form of collaboration can happen even between competing companies; for example, notices of potential security vulnerabilities are commonly shared among different competing Linux vendors. As an example, Mark Cox of Red Hat (a widely used distribution of Linux) analyzed the results of two years of incident responses, and provided the sources for the information, and found that the largest source of vulnerability disclosure was the group of peer FLOSS distributors.

There is no guarantee that simply "dumping" source code on the community will make a FLOSS project appear, and there have been several examples of such behavior to be viewed even negatively, because the community may see this as "garbage dumping" of code. The reality is that for a collaborative community to form, there must be first of all a good communication and interaction strategy and effort in place as a basic requisite. Also, investing in community creation and dissemination efforts does also increase the probability of a bidirectional effort sharing. It is important to mention that surveys like OSSWatch or CIO Insight found a significant proportion of companies and public administrations (between 14% and 25%) contribute back patches or participate actively in FLOSS communities.

Myth #7: Open source software only matters to programmers, since most users never look under the hood anyway.

The fact that most users are not interested in the source code does not imply that having the source code available in itself is useless. Several positive aspects can be identified:

• The availability of the code allows the end user to pay someone for modifications or ongoing maintenance even if the original FLOSS project disappears or becomes inactive.
• "Under the hood" there is not only code, but much non-code artifacts that are vital to a project, like translations, documentation, examples and much more. Many users can contribute in such aspects even as non-programmers.
• For some projects, having the code available allows for a significant cost reduction or dramatically increases the flexibility of the offered solution. For example, in a project called MuleSource (a sophisticated middleware system) it was found that 64% of users perform at least one source code modification.

The important difference with the proprietary world (when sometimes code can be evaluated, but not changed or modified in any way) is that the code is not just a way to reassure buyers in case of bankruptcy of the vendor, but a real and living element. One can conclude that for the non-developing users the availability of source code is a form of "insurance policy", while for advanced users and developers the availability of code allows for deep customization and adaptation.

Even many researchers have proclaimed in one way or another that the freely available nature of the code precludes any potential commercial exploitation. For example⁸: "The GPL effectively prevents profit-making firms from using any of the code since all derivative products must also be distributed under the GPL license". This of course collides with the economic results obtained by companies like HP (that in 2003 reported more than $2.5B in Linux-related revenues), or the $400M revenues reported in 2006 by Red Hat. In an economic analysis by Gosh it is evaluated that:

• Defined broadly, FLOSS-related services could reach a 32% share of all IT services by 2010, and the FLOSS-related share of the economy could reach 4% of European GDP by 2010.
• FLOSS directly supports the 29% share of software that is developed in-house in the EU (43% in the U.S.).
• FLOSS potentially saves industry over 36% in software R&D investment that can result in increased profits or be more usefully spent in further innovation.
• The notional value of Europe’s investment in FLOSS software today is Euro 22 billion (36 billion in the US) representing 20.5% of total software investment (20% in the US).

This directly translates in a significant market (that is difficult to measure, when -- as most consultants do -- evaluated only through licensing sales in the server market).

There are many potential business models based on FLOSS; for a sample of 80 companies and their approach, see Open Source Business Models: a Taxonomy of Open Source Firms’ business models and Business models in FLOSS-basedcompanies [PDF].

This is connected to the view of myth #2, the idea that FLOSS is developed by volunteers, and that companies can only profit in a parasitic way from the code that is developed for free. As discussed in that part, the reality is that in most projects companies and volunteers participate in a collaborative and non-competitive way; also, the most widely used license (the GPL) forces companies to reciprocate their efforts by making dissemination of the source code mandatory whenever there is dissemination of code derived from GPL projects.

The concept of software innovation is really rooted in two different aspects: technical innovation and field innovation. While technical innovation is mostly invisible to the user, "field innovation" (for example a new kind of application) is highly visible, and the perception is widespread that most FLOSS software is more or less a copy of some other desktop-oriented proprietary application.

The reality is that most proprietary software is non-innovative in this aspect too; and that while very few examples of new concepts (like Dan Bricklin's spreadsheet idea) can be found, most applications are matched to the tasks that people perform daily, and as such there is a strong disincentive to innovate away from familiarity. A study of 500 sourceforge projects⁹ found that from a field innovation point of view, around 12% of the projects sampled were considered innovative, a percentage that is comparable to that of the proprietary software market. As for technical innovativeness, the already cited study by Succi, Paulson and Eberlein found that "The hypothesis that open-source software fosters more creativity is supported by our analysis. The growing rate, or the number of functions added, was greater in the open-source projects than in the closed-source projects. This indicates that the open-source approach may be able to provide more features over time than by using the closed-source approach." So, both from a technical and field point of view, FLOSS is on a par or better than proprietary software.

Если кому понадобится Open XML Explained с примерами.
продолжение...

Серия статей " Пересекая границы" рассматривает, как языки программирования, отличные от Java, решают основные проблемы, и что эти решения означают для Java-программистов сегодня. В данной статье исследуется continuation (преемственность), технический прием, лежащий в основе таких интегрированных систем как Smalltalk Seaside. Серверы с преемственностью значительно облегчают создание Web-приложений, предлагая программную модель с сохранением состояния без вреда для масштабируемости, свойственной моделям без запоминания состояния.

Обычная Web-разработка является иногда приятной, а иногда мучительной работой. Java-разработчики проходят длинный путь, предоставляя модель без запоминания состояния, но получаемые в результате производительность и легкость разработки стоят потраченных усилий. В данной статье я рассказываю о радикально отличающемся подходе к Web-разработке, называемом continuation-сервером. Предлагая программную модель с запоминанием состояния, не влияющую на масштабируемость, присущую моделям без запоминания состояния, continuation-серверы значительно облегчают разработку Web-приложений.

О данной серии статей В серии статей " Пересекая границы" ее автор Брюс Тэйт развивает мнение о том, что современные Java-программисты имеют широкие возможности для изучения других подходов и языков. Сфера программирования изменилась после того, как Java-технология стала очевидным лучшим выбором для всех разрабатываемых проектов. Другие интегрированные среды формируют способ построения Java-сред, а концепции, осваиваемые вами в других языках, могут дать новый импульс вашему Java-программированию. Написанный вами Python-код (или Ruby, или Smalltalk, или ...) может изменить способ вашего Java-кодирования. Данная серия статей знакомит вас с концепциями и методиками программирования, которые радикально отличны от Java-разработки, но в то же время напрямую применимы к ней. В одних случаях вам понадобится интегрировать технологию для использования ее возможностей. В других вы будете способны применить концепции непосредственно. Конкретное инструментальное средство не так важно, как идея о том, что другие языки программирования и интегрированные среды могут оказать влияние на разработчиков, среды разработки и даже на фундаментальные подходы в Java-сообществе.

• Производительность часто была ужасной. Одним из преимуществ терминальной разработки является ограничение программной моделью расходов на взаимодействие. После устранения этих ограничений нам стало не хватать пропускной способности, инструментальных средств или квалификации для создания простых распределенных приложений.
• Приложения были не переносимы. Большинство сред разработки клиент-серверных приложений навязывали нам аппаратное и программное обеспечение.
• Приложения были тяжелы в развертывании. Потенциально мы должны были управлять тысячами клиентов независимо.
• Наибольшие затраты были скрыты. Развертывание превращалось в самое серьезное ограничение, поскольку стоимость завершающего этапа внедрения взмывала вверх.

• Ограниченные взаимодействия. Web-модель запрос/ответ обладает всеми характеристиками терминальной разработки. Пользователь вводит информацию в форму, выполняет запрос и получает ответ. "Болтливость" при взаимодействиях исчезла, а производительность повысилась.
• Архитектуры, не использующие общие ресурсы. Основанная на сервлетах модель программирования могла не сохранять состояния. Это означало, что один сервлет мог обслуживать любого клиента, а фиксированный пул сервлетов мог обслуживать намного большее число клиентов. Вы не должны были резервировать сервлет для каждого пользователя. Производительность улучшилась еще больше.
• Общие стандарты для клиентов. Неожиданно, развернув общий браузер у всех клиентов, вы могли создать один интерфейс и взаимодействовать практически со всеми клиентами. Поддержка многих браузеров была проблематичной, но это и близко не было так трудно, как поддержка родных библиотек пользовательских интерфейсов. Многие проблемы переносимости просто исчезли.
• Более совершенная модель развертывания. Используя браузер в качестве стандартного клиентского приложения, стало намного проще распространять разработки. Компания могла развернуть приложение на паре Интернет-серверов и предоставить доступ к ним для всего предприятия. Сетевая архитектура часто могла распределять запросы по нескольким серверам, поэтому увеличить мощность стало так же просто, как установить еще один сервер. Развертывание на стороне клиента было настолько простым, что сводилось к проверке установки у клиента нужного браузера. Обслуживание значительно упростилось.

• Получить идентификатор пользователя от клиента
• Восстановить состояние взаимодействия из сессии
• Обработать пользовательский запрос
• Создать ответ
• Сохранить состояние взаимодействия в сессии
• Послать ответ пользователю

В начало

Основная идея заключается в следующем: вы можете позволить вашей интегрированной среде программирования загрузить состояние вашего приложения перед запросом и сохранить состояние вашего приложения после каждого запроса. Я начну с рассмотрения continuation в языке программирования Ruby.

                

irb(main):001:0> def loop(interrupt)
irb(main):002:1> for i in 1..10
irb(main):003:2> puts "Value of i: #{i}"
irb(main):004:2> callcc {|c| return c} if i == interrupt
irb(main):005:2> end
irb(main):006:1> end
=> nil

                
irb(main):007:0> cont = loop 5
Value of i: 1
Value of i: 2
Value of i: 3
Value of i: 4
Value of i: 5
=> #<Continuation:0x2b5a358>
irb(main):008:0> cont.call
Value of i: 6
Value of i: 7
Value of i: 8
Value of i: 9
Value of i: 10
=> 1  10
irb(main):009:0> cont = loop 8
Value of i: 1
Value of i: 2
Value of i: 3
Value of i: 4
Value of i: 5
Value of i: 6
Value of i: 7
Value of i: 8
=> #<Continuation:0x2b562f0>

irb(main):010:0> cont.call
Value of i: 9
Value of i: 10

• Он гарантирует запоминание состояние между запросами. Интегрированная среда может идентифицировать конкретные continuation в URL и сохранять их в сессии.
• Он предоставляет программную модель с запоминанием состояния. Интегрированная среда может восстановить любую continuation в любое время. Если пользователь подтверждает форму второй раз, continuation может подхватить обработку на более раннем временном отрезке.
• Вы можете отменить continuation на основе бизнес-правил, поэтому легко защитить форму от двойного подтверждения.
• Вы бесплатно получаете поддержку кнопки "Назад". Поскольку у вас без преувеличения имеется состояние выполнения в любой момент времени, интегрированная среда может просто восстановить соответствующую continuation, если пользователь когда-либо нажмет кнопку "Назад".
• Организовать несколько потоков теперь легко, поскольку нет совместно используемых ресурсов. Отсутствие соревнования за ресурсы означает отсутствие большинства проблем многопоточности.

• Continuation могут быть дорогостоящими. Облегчение помещения данных в сессию означает то, что больше пользователей будет помещать больше данных в сессию. Проектировщики интегрированной среды могут уменьшить затраты, используя подход, называемый "частичные continuation", при котором интегрированная среда сохраняет только относящуюся к приложению часть continuation.
• Ужасные URL. Большинство continuation-серверов добавляют странные идентификаторы для continuation.
• Изменение парадигмы работы с пользователем. Если вы используете continuation-серверы повсюду, работа пользователя изменится. Кнопка "Назад" действительно будет работать, и это может дезориентировать некоторых пользователей. Например, нажав кнопку "Назад" после помещение какого-нибудь товара в вашу корзину, ожидали бы вы, что приложение уберет его из корзины?

• Seaside, самый распространенный continuation-сервер, реализован на Smalltalk Эви Бриантом (Avi Bryant). Если вы хотите познакомиться с радикально отличающейся и очень производительной интегрированной средой Web-разработки, выберите Seaside. Работа с ней изменит ваш подход к Java-программированию.
• Интегрированная среда Iowa на Ruby была тоже создана Эви Бриантом под воздействием Web Objects. Сейчас она используется и поддерживается в Ruby.
• Интегрированная среда Wee - это еще одна Ruby-среда, имеющая много характеристик continuation-сервера, но не использующая continuation на родном языке.
• ViaWeb использовала continuation с языком Lisp для получения лучшей производительности по сравнению с конкурентами в 1995.
• Continuity - это написанный на Perl continuation-сервер. Perl 6 будет иметь встроенную поддержку continuation.

В начало

• Эмулирование continuation. Некоторые интегрированные Java-среды используют альтернативные методы для сбора состояния выполнения программы. Lakeshore использует потоки, а Spring Web Flow использует конечные автоматы (более подробно вы узнаете о Web Flow в данной статье позднее).
• Выбор другого языка. Виртуальная машина Java имеет альтернативные языки, которые могут работать поверх нее. Cocoon 2 использует такой подход при помощи Rhino, виртуальной машины, поддерживающей JavaScript, но также и Java.
• Реализация continuation. Этот подход используют контейнер сервлетов Jetty 6, RIFE и WebWork.

                

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE webflow PUBLIC "-//SPRING//DTD WEBFLOW//EN"
        "http://www.springframework.org/dtd/spring-webflow.dtd">

<webflow id="myFlow" start-state="displayForm">

    <view-state id="displayForm" view="form">
        <entry>

            <action bean="myFlowAction" method="setupForm"/>
        </entry>
        <transition on="submit" to="processSubmit">
            <action bean="myFlowAction" method="bindAndValidate"/>
        </transition>
    </view-state>

    <action-state id="processSubmit">
        <action bean="myFlowAction"/>
        <transition on="success" to="finish"/>
    </action-state>
        
    <end-state id="finish" view="success"/>

</webflow>

• Персистенция. Хотя нельзя захватить весь стек вызовов, но вы можете захватить текущее состояние выполнения и даже сохранить текущее состояние.
• Долгоживущие процессы, такие как потоки работ (workflow). Поскольку состояние не зависит от данного стека вызовов, подход более стабилен для таких элементов, как длительные потоки работ.
• Инструментальные средства. Относительно легко создать инструментальные средства для XML.

                
  try {
    if (operator == "plus")
      cocoon.sendPage("result.html", {result: a + b});
    else if (operator == "minus")
      cocoon.sendPage("result.html", {result: a - b});
    else if (operator == "multiply")
      cocoon.sendPage("result.html", {result: a * b});
    else if (operator == "divide")
      cocoon.sendPage("result.html", {result: a / b});
    else
      cocoon.sendPage("invalidOperator.html", {operator: operator});
  }
  catch (e) {
    cocoon.sendPage("error.html", 
      {message: "Operation failed: " + e.toString()});
  }

Обратите внимание на метод sendPage в листинге 4. Этот метод посылает страницу назад пользователю. Вы не увидите какого-либо обычного громоздкого кода для поддержки кнопки "Назад" или для сохранения пользовательских данных в сессии – все это инкапсулировано в среду Cocoon.

                
while (mGuess != answer) {
  print(template);
  pause();
  guesses++;

  if (answer < mGuess) {
    template.setBlock("indication", "lower");
  } else if (answer > mGuess).{
    template.setBlock("indication", "higher");
  }
}

В начало

• Оригинал статьи "Crossing borders: Continuations, Web development, and Java programming".
• "Java Web-сервер: Jetty 6.0 Continuations для Ajax-архитектур": Бэн Галбрэйс (Ben Galbraith) рассказывает о силах в Ajax, влияющих на подход, основанный на использовании continuation.
• "Секреты успешной облегченной разработки, часть 8: Seaside" (Брюс Тэйт (Bruce Tate), developerWorks, ноябрь 2005): Введение в самый популярный и важный continuation-сервер.
• Хакеры и художники Пола Грэхэма (Paul Graham) (O'Reilly, 2004): Одна из многих статей в этой книге подробно рассказывает о начале использования continuation.
• Усовершенствованное управление процессами - Continuations: Этот фрагмент пользовательской документации по популярному проекту Apache Cocoon исследует использование continuation в Cocoon.
• Что такое Iowa: Учебное руководство по Iowa, continuation-серверу в Ruby.
• RIFE/continuations: RIFE/continuations - субпроект RIFE, целью которого является сделать его поддержку continuations на чистом Java доступной в качестве библиотеки общего назначения.
• Экспериментальные continuations в WebWork: Интегрированная среда разработки Java Web-приложений WebWork использует RIFE continuations для своей новой реализации continuation.
• Быстрый старт в Spring Web Flow: Это учебное руководство помогает быстро начать работать с Spring Web Flow 1.0.
• За пределами Java (O'Reilly, 2005): Книга Брюса Тэйта (Bruce Tate) о подъеме и стабилизации развития Java и о технологиях, которые могли бы бросить вызов языку Java в некоторых нишах.
• Зона Java-технологии: Сотни статей по каждому аспекту Java-программирования.

• RIFE: RIFE - это инновационная интегрированная среда, которая использует continuation и многие другие методики, популярные в динамических языках.
• Spring's Web Flow: Spring Web Flow - это общий механизм процессов, предназначенный для определения и выполнения процесса предоставления страниц в Web-приложении .
• Lakeshore: Lakeshore - это основанная на Java интегрированная компонентная Web-среда, на которую оказали решающее влияние Seaside 2 и среда Borges Ruby.
• Jetty 6: Jetty - это контейнер сервлетов на языке Java с поддержкой continuation.
• Seaside: Seaside - это самый популярный и влиятельный continuation-сервер.
• Wee: Wee - это еще одна интегрированная среда Ruby continuations.
• Continuity: Continuity - основанная на continuation интегрированная среда Web-программирования для Perl.

• Примите участие в обсуждении материала на форуме.
• Блоги developerWorks: Подключайтесь к сообществу developerWorks.

		Брюс Тэйт (Bruce Tate) является отцом, горным байкером и байдарочником, проживающим в Austin, Texas. Он автор трех бестселлеров по языку Java, в том числе, победителя Jolt "Лучше, быстрее, легче Java". Недавно издал "За пределами Java"… Он работал 13 лет в IBM, а сейчас является основателем RapidRed consultancy, где специализируется на стратегиях и архитектурах облегченной разработки, основанных на технологии Java и Ruby on Rails.