lktalks

"Я ХОЧУ, ЧТОБЫ ЛЮДИ СМОТРЕЛИ И УЧИЛИСЬ!"

2009-10-11T04:53:00.009+04:00

Рассказ в журнале Wired об уникальной библиотеке Jay-а Walker-а. В библиотеке, а скорее в кунсткамере (в том смысле, в котором её создавал Петр I: "Ежели кто найдет в земле или в воде какие старые вещи, а именно: каменья необыкновенные, кости человеческие или скотские, рыбьи или птичьи, не такие, как у нас ныне есть, или и такие, да зело велики и малы перед обыкновенными, также какие старые надписи на каменьях, железе или меди...") чего только нет. Тут и библия Гутенберга и немецкая шифровальная машина Энигма и один из первых искусственных спутников земли и масса всего замечательного.

Само помещение библиотеки не менее ( а может быть и более) интересно чем экспонаты. Да и хозяин тоже. Вот его рассказ о библиотеке на конференции TED.

Несколько картинок:

(Photo: Andrew Moore)

А вот эти фото с сайта архитектора, создавшего здание библиотеки:

(http://www.markfinlay.com/nr5%20ridgefield11.html)

(http://www.markfinlay.com/nr5%20ridgefield12.html)

(http://www.markfinlay.com/nr5%20ridgefield13.html)

(http://www.markfinlay.com/nr5%20ridgefield14.html)

P.S Краткая справка про собственно хозяина библиотеки. Jay Walker в основном известен созданием сайта продажи билетов priceline.com.
Официальная биография тут: http://www.walkerdigital.com/about_jw.htm

P. P.S. Заголовок поста - это слова Петра Первого - он желал "всякого желающего ... смотреть пускать и водить показывая и изъясняя вещи" в своем "кабинете редкостей". Не совсем та ситуация с библиотекой Jay Walker. Это его частная библиотека и, хотя говорят, что в неё попадают иногда школьники и знаменитости, она тем не менее не является полностью открытой для посетителей. Жалко ... я бы пошел.

Удаленная работа - несколько мыслей

2009-08-31T06:30:00.004+04:00

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

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

Вы должны быть в состоянии предложить удобный способ оплаты ваших услуг. Уточнение: webmoney и yandex-деньги - НЕ являются удобным для всех способом . На самом деле, желательно иметь несколько способов. Самым удобным было бы если бы у вас был банковский счет в долларах, на который можно было бы перевести вам деньги. Paypal тоже работает. Необходимость наличия удобного способа оплаты связана с тем, что когда я начинаю с вами работать, я хочу быть сосредоточен на рабочих моментах: что нужно сделать, когда, как, в какие сроки. Я не хочу думать о "логистике".
У вас естественно должно быть удовлетворительное подключение к интернет:

возможность (достаточно "широкий" канал) разговаривать по скайп или ему подобным программам
email
интернет-пейджер (icq, aim, google talk, тот же скайп)
возможность передавать достаточно большие файлы
наличие ftp (в некоторых проектах)

Мобильный телефон для связи - так чтобы я до вас можно было добраться, когда вы не за компьютером. Понятно, что телефоном этим никто не будет (не должен) злоупотреблять, но он необходим, учитывая разницу во времени.
На письма необходимо отвечать. Даже если ответ состоит в том, что вы сделать ничего не сделали. Отсутствие ответа создает неприятнейшее ощущение того, что вы пропали. Это особенно касается "одиноких волков".
Перед высылкой, код необходимо тестировать. Банально, но иногда создается ощущение, что высланное не запускалось автором никогда. Опять же, особенно касается одиночек.
P.S. По этому поводу могу рассказать два анекдота

Автором известного учебника "Искусство программирования" Дональд Кнут, как то написал в письме: "Beware of bugs in the above code; I have only proved it correct, not tried it" (http://www-cs-faculty.stanford.edu/~knuth/faq.html)
Одного моего коллегу как-то спросили "Ну что, написал программу-то?" Тот ответил: "Да". В этот момент спрашивающий уточнил - "Ну то есть она уже готова?" Ответ был простой: "Нет конечно, я её только написал, но не запускал ещё".

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

Не верь глазам своим

2009-06-26T01:57:00.005+04:00

Если на клетке слона прочтешь надпись "буйвол", не верь глазам своим.
Козьма Прутков.

Нашим глазам нельзя особенно верить. Я думаю многим знакома вот эта оптическая иллюзия (взято тут):

На этой картинке клетки A и B одинакового цвета.

А вот ещё одна иллюзия подобного типа (взято тут):

Здесь синяя и голубая спирали на самом деле одного цвета.

Обе иллюзии легко проверяются при помощи любого графического редактором (Paint-а вполне хватит):

Но на самом деле наши глаза и мозги вообще подвластны разного рода заблуждениям. Про не такие уж и визуальные иллюзии рассказывает Dan Ariely: Are we in control of our own decisions?

P.S.

Подборка иллюзий на сайте Michael Bach: http://www.michaelbach.de/ot/
Автор первой иллюзии Edward Adelson написал статью про восприятие света и оптические иллюзии:
http://persci.mit.edu/people/adelson/publications/gazzan.dir/gazzan.htm

Слайды с первой демонстрации WolframAlpha

2009-05-01T23:25:00.002+04:00

Я недавно рассказывал про выходящую в мае систему WolframAlpha. Появилось видео с первой демонстрацией возможностей системы.

Прямая ссылка: http://www.youtube.com/watch?v=hYhLsQPHNas

Может ли машина мыслить?

2009-04-28T07:39:00.003+04:00

1. Тест Тьюринга или "Может ли машина Мыслить"

В своей знаменитой статье "Computing Machinery and Intelligence", напечатанной в 1950 году в журнале Mind, английский математик А. Тьюринг предложил обсудить вопрос "Может ли машина мыслить?".

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

Играют трое: мужчина (A), женщина (B) и ведущий (неважно какого пола). Ведущий находится не втой же комнате, где игроки. Задача ведущего состоит в том, чтобы определить кто из игроков мужчина, а кто женщина, задавая им различные вопросы. При этом вопросы передаются игрокам в виде текстовых сообщений. Задача игрока A - ввести ведущего в заблуждение. Задача игрока B - помочь ведущему. Ответы игроков также передаются ведущему в виде текстовых сообщений.

Исходный вопрос "Может ли машина мыслить" теперь предлагается переформулировать так:

Что случится, если машина будет играть роль A в этой игре? Будет ли ведущий ошибаться также часто, как в том случае, если роль A играет мужчина?

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

2. Wolfram Alpha

Завтра, 28 апреля 2009 года, для сотрудников Harvard Law School состоится первая открытая презентация нового проекта создателя системы компьютерной алгебры Стивена Вольфрама - Wolfram Alpha. Сам же проект обещают открыть в мае 2009 года. Что такое Wolfram Alpha? Это "система отвечающая на вопросы". Идея состоит в том, что ей можно будет задавать вопросы на естественном языке (английском), а системы будет давать на них точные (по возможности) ответы. Этим она сильно отличается от современных поисковых систем, которые выдают не ответы, а страницы, на которых встречаются ключевые слова.

Примеры:

если ввести “3/26/2009 + 90 days”, то в качестве ответа вернется страница, с числом, на 90 дней отстоящее от 26 марта 2009 года
если ввести "mt. everest height length of golden gate”, то вернется страница, на которой высота горы Эверест будет выражена в длинах моста "Золотые Ворота" в Сан-Франциско
если ввести "how many internet users there are in Europe", то система выдаст точную цифру, а также графики и статистику по отдельным странам
система умеет решать математические задачи - несложные интегралы, производные, уравнения (она же основана на движке Mathematica, как никак)
умеет отвечать на вопросы по физике и химии
вместе с информацией о каждом факте система показывает ссылку на источник

Дополнительные ссылки, если хочется почитать про Alpha:

Исходное объявление Стивена Вольфрама
http://blog.wolfram.com/2009/03/05/wolframalpha-is-coming/
Разные дополнительные статьи

Резюме: Wolfram Apha - это очень мощный способ поиска ответов по различным энциклопедическим источникам.

3. IBM играет в "Jeopardy"

11 мая 1997 года шахматный компьютер Deep Blue выграл матч у действующего чемпиона мира Г. Каспарова (Каспаров правда утверждает, что представители IBM жульничали). Сегодня, 27 апреля 2009 года, компания IBM обнародовала свой проект Watson - систему, распознающую естественный язык и умеющую давать ответы на вопросы в игре "Jeopardy!", аналогом которой является российская "Своя игра". Предполагается что Watson сможет стать полноценым конкурентом игрокам-людям в этой игре. Компьютер, на котором будет работать программное обеспечение Watson - IBM Blue Gene/P.

Ролик: http://www.youtube.com/watch?v=3e22ufcqfTs&feature=player_embedded

4. Что дальше?

Компьютеры пока ещё конечно не научились проходить тест Тьюринга. Но сдается мне, что мы находимся совсем недалеко. Конечно, и система Alpha и Watson - это только шаги, далеко не первые, но и не заключительные. Мы подбираемся к прохождению теста очень близко и это замечательно, так как открывает очень многие дороги.

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

Почитать #4

2009-04-28T06:23:00.001+04:00

The New York Times: David Pogue: "Should you worry about data rot?"
http://www.nytimes.com/2009/03/26/technology/personaltech/26pogue-email.html?_r=1

Про то, что современные носители информации не очень надежны, да к тому же ещё и форматы данных меняются со страшной скоростью. Так что,
по прежнему пытаемся брать количеством копий.
Wolfram Blog: Stepehn Wolfram: "Wolfram|Alpha Is Coming!"
http://blog.wolfram.com/2009/03/05/wolframalpha-is-coming/

Создатель известной системы символьных вычислений Mathematica, рассказывает а своем новом проекте: поисковом двжке, понимающем
естественный язык. Обещает совершенно новый способ получения информации из web. Проект Wolfram|Alpha должен стать публично доступным в мае.
Scientific American: Ray Kurzweil: "The coming merging of mind and machine"
http://www.sciam.com/article.cfm?id=merging-of-mind-and-machine

Про то, как через пару-тройку десятков лет мы создадим компьютеры, способные думать и обладающие эмоциям. А также про то такие компьютеры - эволюционное будуще человечества. (Помните о том, что автор ..ммм ... не совсем обычный человек с неоднозначными взглядами :-) )
The New Yorker: John McPhee: Checkpoints
http://www.newyorker.com/reporting/2009/02/09/090209fa_fact_mcphee

Про то, как работают люди, выверяюшие факты в газетах и журналах. (Требуется регистрация, но денег платить не требуется).

World Wide Telescope

2009-03-26T05:43:00.001+03:00

Если вы ещё не посмотрели World Wide Telescope, тогда мы идем к вам.

Проект вышел из beta статуса и доступен всем желающим. World Wide Telescope - это ответ Microsoft на Google Earth + Google Sky -
программа в которой можно путешествовать по космосу, земле, планетам, галактикам, созвездиям и звездным скоплениям.

Проект создавался в тесном сотрудничестве с NASA и потому количество и качество космических снимков очень, очень впечатляет.

Заметки россыпью:

Страничка проекта на Microsoft Research: http://research.microsoft.com/en-us/projects/wwt/
Вдохновителем продукта был всемирно известный исследователь Jim Grey
NASA передало Microsoft фото с телескопов Hubble, Spitzer и Chandra для использования продукте
Существует веб-клиент (MS Silverlight) - и вроде даже более или менее работает
Windows версию можно подключать к настоящему телескопу и направлять его в интересующую точку неба!!! (требует дополнительного софта, конечно же)
Количество источников изображений впечатляет:

Digitized Sky Survey (Color)
A sky survey in the infrared wavelength created by the Space Telescope Science Institute's (STScI) Catalogs and Surveys Group from the Palomar and U.K. Schmidt telescope photographic sky survey plates. Each plate covers 6.5 x 6.5 degrees of the sky.
Sloan Digital Sky Survey (Color)
A wide-field deep sky survey that will generate detailed images taken at the optical wavelength covering more than a quarter of the sky, determine the positions and absolute brightness of hundreds of millions of celestial objects, measure the distance to more than one million galaxies and 10,000 quasars, and produce a three-dimensional picture of the universe.
Hydrogen Alpha
A full sky map generated by Douglas Finkbeiner at Princeton University compositing the Virginia Tech Spectral line Survey (VTSS) in the northern hemisphere and the Southern H-Alpha Sky Survey Atlas (SHASSA) in the southern hemisphere. The hydrogen-alpha filters block out as much of the hydrogen emission spectrum leaving only a bandpass from 0.5 Angstrom to 1 Angstrom deep in the red end of the visible light spectrum.
IR Dust Map
The Infrared (IR) Dust Map is an all-sky, 100 micron, far infrared (12, 20, 25, and 100 micron passbands) survey modulated by dust temperatures and then calibrated to be dust reddening in magnitudes.
WMAP Microwave Cosmic Background
The Wilkinson Microwave Anisotropy Probe (WMAP) was a three-year, all-sky survey that concluded in 2006. The survey was conducted at several microwave bands (K, Ka, Q, V and W) to measure and map the cosmic microwave background radiation and its fluctuations.
US Naval Observatory B1.0
An inclusive all-sky catalog from the U.S. Naval Observatory Flagstaff Station (USNOFS) Precision Measuring Machine project. It contains over 1,042,618,261 entries for stars and galaxies. Every point on the sky is covered at several epochs and at several wavelengths, making it possible to construct a catalog that includes positions, proper motions, optical colors, star-nonstar discriminators, and the appropriate uncertainties.
2MASS (Synthetic)
A whole sky survey created using three photometric near-infrared bands to detect and characterize point sources brighter than about 1 milliJansky (mJy) in each band, with signal-to-noise ratio (SNR) greater than 10, using a pixel size of 2.0".
Tycho Synthetic
The Tycho-2 catalog is based on a mix of 1991 space-based data from the European Space Agency's Hipparcos satellite, data from the Tycho 1 catalog, and over 140 astrometric catalogs. The catalog also included the re-analysis of positional data for the Tycho-1 stars and increased the number of stars in the catalog to 2.5 million.
RASS X-Ray
The ROSAT All Sky Survey (RASS) was a survey of the sky released in March 2000 by the Max-Planck-Institut für extraterrestrische Physik. Its two objectives were to create the first all-sky survey with an imaging X-ray and extreme-ultraviolet (EUV) telescope and a detailed study of selected X-ray and selected EUV sources.
VLSS Radio
The Very Large Array Low-Frequency Sky Survey (VLSS) is a 74 MHz (4-meter wavelength) continuum radio survey consisting of 358 continuum images covering the entire sky north of -30° declination.

Можно смотреть картину звездного неба, двигаясь во времени, то есть, например, увидеть небо таким, каким его видели 2000 лет назад
Ну можно конечно смотреть землю, в том числе карту и "street view"
Можно смотреть все изображения с

Spirit и Oportunity (Марс)
Pathfinder
Apollo 11-17 (луна)

Можно смотреть землю ночью
Можно создавать туры с аудио, аннотациями и некоторые уже опубликованы
"Можно грабить корованы" :-)

почитать #3

2009-03-10T17:52:00.002+03:00

Элементы: А. Марков: "Популярность креационизма в Европе объясняется не религиозностью, а научной безграмотностью"
http://elementy.ru/news/431014

О том, что распространение креационизма не является только американской проблемой.

The New York Times: Dennis Overbye: "In a lonely cosmos, a Hunt for Worlds Like Ours"
http://www.nytimes.com/2009/03/03/science/03kepl.html

О запуске телескопа Кеплер, целью которого будет поиск планет, похожих на землю.
The Long Now Blog: "History of LIfe in 60 Seconds"
History of Life in 60 seconds
Одноминутный ролик о том как развивалась жизнь на земле. Возникновение человечества практически невозможно заметить, настолько это маленький отрезок, по сравнению со всем остальным.
The New York Times: "They Tried to Outsmart Wall Street"
http://www.nytimes.com/2009/03/10/science/10quant.html?_r=2&pagewanted=all

О том, как ученые пытались и продолжают пытаться математически моделировать процессы, происходящие на фондовом рынке.
На закуску: старый ролик английских комиков John Bird и John Fortune, в котором они рассказывают про экономический кризис. Отличется тем, что кризис в этом ролике предсказан, поскольку программа вышла существенно раньше того как все обвалилось.

Прямая ссылка: http://www.youtube.com/watch?v=mzJmTCYmo9g&eurl=http://video.google.com/videosearch?hl=en&rlz=1C1GGLS_enUS291US303&q=bird%20fortune&um=1&ie=UTF-8&saiurl=http://i2.ytimg.com/vi/mzJmTCYmo9g/hqdefault.jpg&feature=player_embedded

Amazon Kindle 2 и Unicode

2009-03-09T19:42:00.001+03:00

Недавно, 24 февраля компания Amazon начала поставки своей "читалки" электронных книг Kindle 2.

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

Ну что тут сказать. Первая версия Kindle была выпущена в конце 2007, вторая соответственно в 2009. Unicode консорциум был образован в январе 1991 года. 17 лет всего прошло, это конечно немного.

Я могу довольно легко понять, что Kindle - устройство в основном расчитанное на американский рынок и все такое. Тем не менее, идея что в 2008, ну или скажем 2007 или 2006 (когда они начинали писать firmware) программисты сядут и напишут не unicode программу, тем более программу которая является читалкой книг, блогов, газет и к тому же web-браузером, кажется мне диковатой.

P.S. Может быть программистам Amazon стоит прочитать небольшую статью Joel Spolsky: The Absolute Minimum Every Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!). Шутка. На самом деле я почему-то уверен, что это было бизнес решение.

почитать #2

2009-03-02T20:25:00.002+03:00

TED Talk: Sylvia Earle: "Here is how to protect the blue heart of the planet"
http://www.ted.com/talks/sylvia_earle_s_ted_prize_wish_to_protect_our_oceans.html

О том, что происходит с мировым океаном и о том, что нужно создавать морские заповедники, пока вся рыба не кончилась
Элементы: А.А. Зализняк "О профессиональной и любительской лингвистике"
http://elementy.ru/lib/430720?context=369876

О том, что не надо верить в то, что "Государство древнее Урарту образовалось из Урюпинска и Тарту". (с) Тимур Шаов. Также несколько перекликается со статьей "Об исторической лингвистике", на которую я ссылался в прошлом выпуске. Замечательные мысли про опасность веры в то "что все мнения одинаково ценны".

почитать

2009-02-23T20:37:00.002+03:00

Время от времени мне попадаются в сети интересные статьи, видео, которые заставляются задуматься о чем-то большем чем системы контроля версий, принцип DRY,вопросе о том как распознать шрифт по его изображению или что подразумевается под названием дожности "Team Leader". В этом еженедельном обзоре я попытаюсь выкладывать список ссылок на подобные "вкусности". Вот список попавшегося мне за прошлую неделю (Сами публикации не обязательно случились на прошлой неделе, просто я их на этой неделе прочитал/просмотрел).

Замечание: если заголовок английский, значит текст или видео - на английском языке.

TED Talk: Juan Enriquez: "Beyond the crisis, mindboggling science and the arrival of Homo evolutis."
http://www.ted.com/talks/juan_enriquez_shares_mindboggling_new_science.html

О будущем человечества, как вида.
The Economist: "What's Cooking?"
http://www.economist.com/science/displayStory.cfm?story_id=13139619

О том, как употребление приготовленной пищи повлияло на развитие Homo sapiens.
TED Talk: Jill Tarter: "Why the search for alien intelligence matters."
http://www.ted.com/index.php/talks/jill_tarter_s_call_to_join_the_seti_search.html

Директор SETI Institute о поиске внеземных цивилизаций.
The New York Times: Steven Pinker: "My Genome, My Self"
http://www.nytimes.com/2009/01/11/magazine/11Genome-t.html?_r=1&hp=&pagewanted=all

Профессор психологии Гарвардского университета, участник "Personal Genome Project" о том, как расшифровали его геном.
Элементы: А.А. Зализняк: "Об Исторической Лингвистике."
http://elementy.ru/lib/430714

О том как языки развиваются во времени. Не Фоменко.
Замечание: это лекция для школьников, отсюда и стиль изложения.
The New York Times: John Markoff. "Do We Need a New Internet?"
http://www.nytimes.com/2009/02/15/weekinreview/15markoff.html

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

The Ultimate Reboot

2009-02-21T04:40:00.003+03:00

Вот интересное мнение о будущем ... всего человечества (на английском, 18 минут)

UPDATE:

Прошу прощения, если видео сразу оказалось не видно, то вот прямая ссылка: http://www.ted.com/talks/view/id/463

И снова про Fog Creek

2009-02-08T17:46:00.002+03:00

Я неравнодушен к хорошему офису. Поэтому и следил пристально за Fog Creek Software, создатели которой заявляют, что: "A programmer is most productive with a quiet private office, a great computer, unlimited beverages, an ambient temperature between 68 and 72 degrees (F), no glare on the screen, a chair that’s so comfortable you don’t feel it <...>". И даже некоторое время назад сходил к ним в офис, посмотреть своими глазами, правда ли все то, что они о себе пишут.

Время идет, компании разваливаются или наоборот, расширяются. Выясняется, что несмотря на кризис, Fog Creek Software чувствует себя вполне нормально. Они переехали в новый офис.

Картинка стоит тысячи слов:

http://picasaweb.google.com/spolsky/FogCreekSNewOffice

Вообще, я не знаю какой Joel Spolsky программист и руководитель, но он, видимо, очень хорошо разбирается в маркетинге. Его популярность как блоггера, я думаю, существенно выше популярности программных продуктов его компании. Более того, если до сих пор он был "широко известен в узких кругах", то сегодня произошло на мой взгляд совершенно уникальное событие. Описание офиса его компании появилось в New York Times, одной из самых влиятельных американских газет. Так что, думаю с сегодняшнего дня, компания Fog Creek Software стала по-настоящему широко известна.

Попытка написать рассказ ...

2008-12-03T06:39:00.004+03:00

Таксист внезапно притормозил и Саша чуть не ударился головой о пластиковую перегородку, отделявшую его от водителя. "Чёртовы светофоры!" Лекция начиналась через пять минут, а тут, как нарочно, практически на каждом перекрестке был красный. Машина наконец тронулась, и Сашу вдавило в сиденье (таксисту было обещано не обидеть, если довезет быстро). Через 6 минут такси остановилось перед зданием публичной библиотеки, Саша бросил таксисту двадцатку и, не дожидаясь сдачи, выскочил из машины и взбежал по ступеням. "Алекс, да где же вы пропадаете!" - встретил его голос куратора библиотеки - седые волосы, черный смокинг, бабочка - "Вперед! Вперед!" Вслед за пожилым куратором, Саша буквально ворвался в главный зал.

"Итак, то чего мы все так долго ждали и ради чего собрались. С удовольствием представляю нашего уважаемого гостя. Профессор математики и главный исследователь Массачусетского Технологического Института, кафедра суперкомпьютеров: Алекс Сосновский". Пожилой куратор протянул руку, приглашая Алекса на сцену. Только когда Саша взял в руки микрофон, он понял, что на самом деле страшно волнуется. Волноваться было, в сущности, совершенно нечего. Саша был готов - полностью, стопроцентно, хотя и совершенно не готовился к лекции. Говорят, что первого советского наркома просвещения А. Луначарского как-то попросили прочитать лекцию в одном институте. Тот сразу же согласился и прочитал лекцию совершенно без подготовки. "Как же вам удается читать такие блестящие лекции совершенно без подготовки?" "Как это без подготовки? Я готовился к этому всю свою жизнь"- был ответ. Так же и сейчас. Саша готовился к этой лекции всю свою жизнь. Сегодня он, наконец, сможет рассказать всему миру о своем открытии. Что он, наконец, сделал то, о чем мечтал мальчишкой в маленькой квартирке на окраине Москвы.

----------

Первый раз Саша (тогда Шурик) узнал о компьютерах в школе. В тот день Филька - главный школьный хулиган, первый раз за все время молчал во время урока. Это было настолько необычно, что даже Татьяна Игоревна, их учительница, во время перемены подошла к Фильке и озабоченно спросила что случилось. Филька, однако, загадочно продолжал молчать. Когда же уроки, наконец, кончились и все мальчишки собрались в школьном дворе, Филька торжественно объявил: "А у меня дома компутер!". Признаться, мальчишки, включая и Сашку, не были особенно впечатлены этим заявлением. К тому же Филька не мог толком объяснить, что же это такое - компутер. Однако вся ватага помчалась к Фильке домой смотреть на чудо. Войдя в комнату, они увидели на письменном столе его. "Компутер" оказался железной коробкой с огромным количеством тумблеров и не меньшим количеством лампочек. Лампочки мигали. Это было совершенно непонятно и большинство из ватаги, быстро разочаровавшись, помчались на улицу играть в футбол. Филька же с Шуриком остались. Мигающие лампочки завораживали. "А как в него играть?" "Дядя Витя покажет". В этот момент из кухни вышли двое - Филькин дядя Витя, красивый высокий человек с русыми волосами и ещё кто-то - среднего роста, неприметный, в простеньком сером костюме. "Дядя Витя, здрасте! А как играть в компутер?" - бросились к нему Филька с Шуриком. Дядя Витя, однако, как будто не обратил внимания на мальчишек. Они лишь обменялись с неприметным человеком нахмуренными взглядами. Сразу после этого дядя Витя быстро упаковал "компутер" в оберточную бумагу, положил в картонную коробку с непонятной надписью и мужчины вышли.

Филькин дядя был дипломатом, что всегда страшно веселило мальчишек, поскольку это конечно смешно, если человек работает небольшим чемоданчиком. Дипломатическая работа дяди Вити, тем не менее, и дала ему возможность привезти в СССР эту железную коробку с тумблерами и лампочками. Только через пять, уже взрослыми, как им тогда казалось, Шурик и Филька осознали, что в Филькиной квартире они тогда видели первый персональный компьютер в мире Altair, компании MIPS. Шел 1974 год. Именно в тот год руководитель компании MIPS Эд Робертс предпринял все возможные усилия, для того, чтобы произведенный его компанией компьютер попал на обложку журнала Popular Electronics. Пробный экземпляр был послан редактору журнала Лесу Соломону. Известно, что он был послан поездом в Нью-Йорк, где находилась редакция, однако редактор так его и не получил. Журналисты напечатали на обложке фотографию пустого корпуса того, чему предстояло стать предвестником новой эры: первого в мире персонального компьютера. Никто не обратил внимания, на что, что утром, после прибытия на центральный вокзал Нью-Йорка, из поезда вышел человек среднего роста и неприметного вида, в простеньком сереньком костюме. В руках у него была картонная коробка с рекламой супов быстрого приготовления.

К восьмому классу Шурик и Филька уже не спрашивали "Как играть в компутер". Мигание лампочек так заворожило их в тот день после школы, что они только этим и занимались. Вдвоем они проводили ночи напролет в институте, где работал папа Шурика, и учились программировать. И не было никого более увлеченных людей, чем они. Больше всего ребят интересовал вопрос, как сделать так, чтобы программы работали чуть-чуть быстрее. В какой-то момент Шурик понял - они не могут больше улучшать сами программы - нужно улучшить сами компьютеры. Тогда они стали вдвоем собирать собственный компьютер. В десятом классе Александр Сосновский и Филлип Надеждин представили на всесоюзном конкурсе молодых изобретателей компьютер собственного изготовления. Только внимательный наблюдатель заметил бы, что контрольные лампочки были в точности такие, как у первого компьютера Altair.

Сразу после окончания института Саша и Филлип были распределены в Научно Исследовательский Институт Вычислительных Комплексов под руководством потрясающего советского конструктора компьютеров М. А. Карцева. В то время в институте велись работе по созданию компьютеров исключительно советского производства и конструкции, многие из которых были существенно лучше имеющихся в то время американских аналогов. Саша и Филлип страшно увлеклись - сам Карцев понял, что он получил двух великолепных инженеров. Они вдвоем были выделены в отдельную лабораторию, где и посвящали все свое время созданию архитектуры нового, ещё более мощного компьютера. К их огромному сожалению планы в стране изменились, и вместо создания оригинальных компьютеров было решено копировать западные образцы. Не все однако, занимались копированием. Небольшая лаборатория, состоявшая всего из двух человек, продолжала активно заниматься разработками собственных оригинальных конструкций.

----------

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

Подобные компьютеры изначально создавались для проведения очень специализированных вычислений: вычислений, необходимых для расчета атомной бомбы, для моделирования хода и последствий атомной войны, предсказания погоды, задачи шифрования и дешифрования текстов, астрономических, биологических и других расчетов. Постепенно их мощь стала применяться для самого широкого рода исследований.

Первые суперкомпьютеры были разработаны в компании Control Data Corporation в США в 60-х годах двадцатого века основателем компании и её главным идеологом Сеймуром Креем. Впоследствии многие компании разработали собственные суперкомпьютеры, в том числе и такие, которые были организованы из множества "маленьких", "персональных" компьютеров, объединенных вместе.

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

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

Саша продолжал лекцию ещё около часа, подробнейшим образом описывая свое детище, рассказывая о хитроумных решениях, выстраданных ими с Филлипом за долгие годы разработки. И чем ближе он придвигался к концу лекции, тем больше ему хотелось скорее отсюда сбежать, вернуться в лабораторию и, наконец, включить машину. Новая машина принципиально отличалась от многих других тем, что представляла из себя компьютер общего назначения, то есть не была предназначена для решения только одной специализированной задачи. Она могла решать любые задачи, просто она страшно быстро считала.

Через 2 минуты после того как замолкли последние аплодисменты Саша уже снова сидел в такси. "В аэропорт!" - скомандовал он. В Бостоне, в здании его небольшой лаборатории все его восемь сотрудников (лаборатория не сильно расширилась со времен НИИВК, но все-таки расширилась) встречали его у входа. "Ну что, включаем?" - хор голосов слился в вопросе. "Включаем!". Саша протянул руку, и палец легко нажал кнопку включения. Хлопнула пробка от шампанского, открытого кем-то из ребят! "Ну что? Заработало!".

----------

Вот уже восьмой час Ганс Брюгер пытался победить тролля-охранника моста. Создание было настолько сильным, что как Ганс не пытался, тролль постоянно его побеждал. Ганс каждый раз заново возрождался в болоте. А убить тролля было очень важно, иначе Ганс не мог продвинуться в основном задании, где трольь был только первым шагом. Но, чтобы убить тролля, ему нужно было набрать больше опыта, а без выполнения задания опыта не набрать. Заколдованный круг какой-то получается. Недаром игра - самая популярная многопользовательская игра этого года - так и называлась - "Заколдованный круг". Миллионы людей в неё играют по всему миру и Ганс в их числе, но вот же незадача никак не может убить мерзкого тролля. "Хрлюююп!"- снова сказал тролль, и игрок увидел знакомые очертания болота. В этот момент в правом нижнем углу замигала желтая иконка системного сообщения. "Хоть какое-то развлечение" - подумал Ганс и вывел сообщение на экран. "Компания "Заколдованный круг" сообщает о введении в строй нового игрового сервера, который в состоянии поддержать одновременную работу дополнительных ста миллионов пользователей, которые по нашим прогнозам подключатся к игре в этом году. "Эх, фигня какая-то"- подумал Ганс и вернулся к своему троллю.

Рынок, Роботы, Люди

2008-09-16T19:07:00.004+04:00

Сейчас, как известно, финансовый кризис. И вот на его фоне прочитал совершенно удивительную историю. Оригинал можно прочитать тут.

Итак, в один прекрасный день, акции одного из крупнейших авиаперевозчиков США United Airlines падают почти в 4 раза, вот так, как этот провал на графике:

(график взят тут)

Что же произошло? У меня здесь не финансовый блог, так что не пугайтесь.

Пролог (рынок)

декабрь 2002 года, Чикаго

В 2002 году компания United Airlines испытывала значительные финансовые трудности и, в итоге, объявила себя банкротом. В декабре 2002 года в газете Chicago Tribune была по этому поводу опубликована статья.

Роботы

6-7 сентября 2008 года, Интернет (Флорида, Калифорния, Нью-Йорк)

восточное время (7 сентября), 00:08

Чуть позже полуночи ссылка на статью 2002 года каким-то образом появилась в списке "самых просматриваемых" ссылок сайта газеты The Sun Sentinel, принадлежащей той же компании, которой принадлежит и Chicago Tribune, а потому пользующейся общим с ней архивом старых выпусков.

западное время (6 сентября), 21:23

Робот автоматической службы новостей Google News обнаружил ссылку на сайте The Sun Sentinel, обработал страницу и посчитал её новостью, поскольку в самой статье даты не было, зато страница содержала текущую дату. Тогда робот добавил новость в индекс, проставив ей то число, когда он её нашел, то есть ... 6 сентября 2008 года (поскольку Google находится на западном побережье США и там 7 сентября ещё не наступило). На главной странице Google News новость видна не была, но она была видна в поиске, а также была выслана по почте и RSS рассылкам, тем кто был подписан на новости с определенными ключевыми словами в них.

восточное время (7 сентября), 8: 15

Сотрудник компании Income Security Advisors получил уведомление от Google News о новости про авиакомпанию и немедленно выслал информацию в информационное агенство Bloomberg, специализирующееся на финансовых новостях. Которое, в свою очередь, быстро выдало информацию "в эфир".

восточное время (7 сентября), 9:02

Акции United Airlines рухнули, но очень быстро выяснилось, что "новость" о банкротстве является ошибочной и акции восстановились почти до прежнего уровня.

Люди

17 сентября 2008

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

А я вот о чем подумал. Я вполне легко могу себе представить все случившиеся "технологические" ошибки. Нет даты на странице. Запросто. Дата есть, но она всегда текущая. Легко. Статья 2002 года непонятно как попавшая в список "Самые просматриваемые". Элементарно. Бот, проиндексировавший именно эту статью. Естественно.

Что мне трудно понять, так это то, что профессиональный сотрудник Income Security Advisors не проверил новость просто потому, что она получена от Google.

Мне начинает казаться, что нужно обучать людей отличать достоверную информацию в интернете от недостоверной.

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

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

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

P.S. Времена (00:08 и т.п.) происходящих событий выдуманы, остальное вроде так и было.

Программирование и игра в ГО

2008-09-07T04:08:00.003+04:00

Забавная статья: http://railspikes.com/2008/7/14/why-programmers-should-play-go.

На самом деле любители го уже давно утверждают что игра помогает добиться лучших результатов в разных занятиях, требующих похожих навыков: бизнесе, военном деле, теперь вот и в программировании.

Не знаю. Но поиграть вполне можно :-) Я играю иногда, правда не так часто, как хотелось бы.

P.S. Ну вот, написал, отвлекся и вижу, на RSDN это уже обсуждают. Все равно нажму publish :-)

Fog Creek Open House

2008-07-26T07:56:00.002+04:00

В четверг (17 июля) сходил на Fog Creek Open House.

Краткое пояснение для тех кто случайно не знает про FogCreek: есть такой сайт www.joelonsoftware.com, на котором человек по имени Joel Spolsky пишет разные интересные статьи на программистские и около программистские темы. Также у этого человека есть собственная компания, разрабатывающая программы. Эта компания и называется Fogcreek Software. Joel Spolsky многократно упоминает в своем блоге (которым сайт joelonsoftware собственно и является) о том, как важны правильные условия работы для успеха программистской компании и о том, что он то уж у себя создал самые лучшие возможные условия труда для программистов. Апогеем является наверное статья "Bionic Office", в которой подробно описываются чудеса офиса FogCreek.

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

Вот и сходил. Ну что сказать ... все правда. Ну почти. Действительно у большинства программистов собственные кабинеты, хорошая техника. Самая аккуратная серверная которую я видел. Шикарная техническая библиотека. Аквариум с рыбками. Каждый день привозят обед, что для американских компаний не очень распространено. 4 недели отпуска, что для американских компаний тоже не очень распространено.

Самым удивительным наблюдением было то, насколько у людей все аккуратно. Старые номера MSDN Magazine разложены в ящики по годам. Может, конечно, они их не читают, или ко дню открытых дверей специально подготовились.

В общем, впечатления самые положительные.

Возник в голове вопрос, сколько же компания собственно зарабатывает, чтобы обеспечивать сотрудникам нормальные условия (утверждается, что зарплаты у них тоже на уровне, хотя точных цифр конечно никто не называл). При том, что продукты, которые они делают, я бы не назвал самыми"денежными". FogCreek делает баг-трекинг систему (FogBugz), сайтопостроитель (CityDesk) и аналог WebEx или GotoMeeting (CoPilot). При этом они не являются лидерами ни по одному из направлений. Небольшой поиск дал следующие результаты:

Year	2007
Industry	Software
Founded	2000
Growth	423.2%
2003 Revenue	$566,576
2006 Revenue	$3.0 million
Employees	11

Конечно не Google, но на кусок хлеба с маслом им вполне хватает :-)

Ещё немного про Google

2008-07-02T22:43:00.002+04:00

Для тех кто ещё не читал этот рассказ, я думаю будет интересно:

Рассказ Сергея Соляника, который работал в Microsoft, потом перешел в Google, а теперь снова вернулся в Microsoft. В рассказе объясняется почему.

P.S. В комментариях есть интересная ссылка: Google C++ Style Guide.

Последний день Билла Гейтса

2008-06-27T17:16:00.002+04:00

Сегодня кончается целая эпоха. Билл Гейтс уходит из Microsoft.

http://www.microsoft.com/presspass/exec/billg/videos/

5 программ, которые я использую ежедневно

2008-06-19T05:16:00.006+04:00

Вот и меня посчитали. До меня дошла игра в 5 инструментов, которая как мне казалось уже закончилась :-) К тому же, про многие мои инструменты я уже писал в посте "Джентльменский Набор". Тем не менее с удовольствием напишу про то, чем пользуюсь именно каждый день и не только про portable :-)

Файловый менеджер - уже несколько лет - Total Commander
Основной браузер - Mozilla Firefox
Miranda и Skype - для мгновенных сообщений
Почтовый клиент(рабочий), календарь, список задач: MS Outlook
Почтовый клиент(личный) - gmail.com
Редактор(заменитель notepad): EditPlus
Разработка (хотя последние несколько месяцев непосредственно разработкой практически не занимаюсь)

C++ - Visual Studio
Разработка Java -IntelliJ Idea
XSL - Altova XML Spy

Ну вот, получилось правда не 5, а чуть больше инструментов, но они ведь все хорошие, как я их мог упустить :-)

P.S. Поскольку то что мы тут делаем - это типичная пирамида, то я конечно должен теперь написать здесь список блогов людей, об инструментах которых мне было бы интересно узнать. К сожалению большинство из них в игре уже поучаствовали, а другие боюсь не читают этот блог. Но, попытка - не пытка. Мне было бы интересно узнать про инструменты которыми пользуются:

Про офис

2008-06-18T04:42:00.000+04:00

Нужен ли офис в программистской компании? Почему бы собственно программистам не сидеть дома, писать себе спокойно программы? Интернет сейчас быстрый поставить недорого. Средства обмена информацией есть в огромном количестве - недорогие и много чего умеющие. Электронная почта, телефон, разнообразные интернет-пейджеры, в том числе и поддерживающие разговоры голосом, телеконференции. Да и показать что происходит можно легко - есть и WebEx и Netmeeting и GoToMeeting и ещё масса подобных программ.

Зачем же нужен офис - за него ведь деньги платить нужно[имеется ввиду за аренду], к тому же в него нужно ездить - тратить время на дорогу.

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

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

Про письма

2008-05-07T04:16:00.004+04:00

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

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

Есть масса вещей, способствующих непрозрачности команды программистов. Языковый барьер, который присутствует просто потому что для одних родной язык русский, а для других английский. Сам факт того что люди сидят далеко друг от друга. И ещё отсутствие писем.

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

Пишите письма!

Отчет об ошибке

2008-03-10T02:19:00.004+03:00

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

Поэтому я завязываю с предисловием и перехожу к сути дела.

Перед тем как добавить новый отчёт об ошибке (новый баг, CR типа дефект, называйте как хотите) необходимо убедиться что его ещё нет в системе.
Уточнить о какой версии продукта (и модуля, и если нужно подмодуля) идет речь. До последней цифры, даже если их 18.

Например: Программа Феликс, версия 4.2.1121.1356b
Описать проблему в примерно таком порядке:

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

Ввести операцию сложения (ну может Феликс в польской записи работает :-) )
Ввести '-2' в качестве первого аргумента
Ввести '-3 в качестве второго аргумента
Нажать на кнопку получения результата

Ожидаемый результат - вы думали что когда это проделаете, то получится то-то
Ожидали получить -5
Полученный результат - а на самом деле получилось ....
Получили -1
Существует ли способ получить ожидаемый результат (способ обойти ошибку)? Если да, то какой?
Да, если сначала ввести -3, а потом -2 то сложение выполняется верно

Все сообщения об ошибках должны быть обязательно приведены (желательно в виде скриншота)
Сообщений об ошибках не выдаётся

И все ...

P.S. Зачем нужен пункт, описывающий способ обойти ошибку (если он существует)? Во-первых, для удобства приоритезации. Ошибкам обычно присваивается приоритет и часто ошибке которая не приводит к полной потере работоспособности имеет смысл присвоить более низкий приоритет. Во-вторых, часто описание способа обхода дает разработчиками ключ к пониманию того, почему же собственно программа неправильно работает.

А вы читали "Искусство программирования"?

2008-01-18T21:02:00.000+03:00

Прошлый пост был посвящён Дональду Кнуту и, в частности, в нём упоминалась самая известная его книга "Искусство программирования". К посту был сделан следующий комментарий:

И мне тоже стало интересно. Посему я создал голосование на известном программистском ресурсе RSDN.

Для тех кто с RSDN не знаком, два небольших замечания:

RSDN - очень "профильное" и довольно высокопрофессиональное место
В голосование можно было добавлять свои варианты ответа, так что первые пять вариантов ответа - это то, что я предложил, а остальное добавлено самими участниками

Вот результаты этого голосования:

Если честно, голосование ещё не закончено и результаты могут немного измениться, но мне кажется что тенденция ясна уже сейчас.

Вот такой вот ответ на вопрос.

P.S. По ссылке с сайта "Информатика в России" нашёл видео-подборку лекций Кнута. Это лекции, которые он время от времени читает в Стэнфорде.

P.P.S. Удивительно, как все-таки формируется наше "мнение" о той или иной работе, книге, статье. Порой репутация автора или людей, его рекомендовавших существенно больше влияет чем собственное мнение о конкретной работе. Да наверное даже в большинстве случаев это так - мнение то у нас есть много о чем, а основано оно на чем? На вере в авторитеты. Репутация авторов - часто единственное на что можно ориентироваться, если ты не специалист в предмете.

Дональду Кнуту исполняется 70 лет

2008-01-10T18:49:00.000+03:00

Сегодня - 10 января - день рождения Дональда Кнута - всемирно известного автора "Искусства программирования".

Кнут - удивительный человек, написавший удивительные книги, в первую очередь конечно "Искусство ..." - книга, которая заняла огромную часть его жизни и которая все ещё не закончена. По замыслу, она должна содержать в себе все знания, необходимые для программирования машин традиционной архитектуры. Сейчас, как известно, существуют первые три тома, несколько кусков четвёртого и дополнения к ним (вещи, которые должны были попасть в первые тома, но ещё не существовали тогда, когда Кнут их писал). Пятый том планируется закончить к 2015 году.

Цитата из предисловия к "Исскусству":

"Полный набор книг, озаглавленный как Искусство программирования, имеет следующую основную структуру.

Том 1. Основные алгоритмы

Том 2. Получисленные алгоритмы

Том 3. Сортировка и поиск

Том 4. Комбинаторные алгоритмы

Том 5. Синтаксические алгоритмы

Глава 9. Лексикографический поиск

После этого планируются ещё 6 и 7 тома. Подробное описание можно найти на собственной страничке Кнута, посвящённой "Искусству".

Кнут также известен созданием системы Tex. А ещё есть масса занимательных фактов из жизни этого неординарного человека:

Кнуту принадлежит высказывание: "Beware of bugs in the above code; I have only proved it correct, not tried it.''
Кнут выплачивает 2 доллара 56 центов любому, кто найдёт ошибку в любой из его книг (потому что 2.56 - это один шестнадцатеричный доллар)
Кнут пользовался электронной почтой с 1975 по 1990 год, после чего решил что для него этого вполне достаточно - с тех пор он не пользуется электронной почтой

P.S. Ну и популярность конечно тоже не обошла Кнута стороной :-)

MRD: Marketing Requirements Document

2008-01-05T06:42:00.000+03:00

Уже почти год назад я писал о ролях в разработке программного обеспечения. А именно о том, в чем состоят обязанности людей, играющих определённые роли и на чьей стороне (заказчика или разработчика) они играют.

Однако, необходимо помнить, что между ролями (на самом деле конечно между людьми, играющими эти роли) постоянно происходит взаимодействие. И от того насколько оно гладкое, налаженное, может зависеть успех проекта. Конечно все вышеизложенное сильно зависит от размеров компании и проекта. В маленьких компаниях больше неформального, дружеского взаимодействия, не требующего иногда никаких формальных документов (ну или требующее их очень малое количество). В больших же коллективах без "бумажки" иногда не обойтись никак. Связано это с тем, что чем больше коллектив, принимающий участие в проекте, тем больше времени тратится на обмен информацией между сотрудниками.

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

Я хочу сегодня рассказать про один из аспектов взаимодействия Product Manager (в терминах моей старой статьи) с разработчиками, заказчиками и высшим руководством.

Замечу, что под разработчиками здесь я понимаю не только программистов, но также и тестировщиков и технических писателей и работников технической поддержки и специалистов по внедрению. Соответственно "команда разработчиков" включает в себя (при необходимости конечно) всех этих людей.

Напомню, что Product Manager:

Отвечает за продукт с точки зрения заказчика. То есть product manager — это человек, представляющий заказчика в команде разработчиков. В обязанности Product Manager входит:

Исследование рынка
Выявление потенциально нужных заказчикам продуктов, сервисов, функциональности
Исследование конкурентов (иногда этим занимаются специально выделенные люди)
Маркетинговые исследования, PR акции, пресс-релизы (иногда эту работу делают специальные Product Marketing Manager, иногда она производится совместно этими двумя ролями)
Выработка списка "features" продукта
Определение приоритетности тех или иных "features" (что делать обязательно, что нет)
Позиционирование продукта (на какой рынок продукт нацелен, портрет покупателя)
План развития продукта (RoadMap)
Ценообразование (сколько продукт будет стоить, какая будет модель лицензирования)
Взаимодействие с высшим руководством компании, если таковое необходимо
Взаимодействие с отделом продаж и совместная выработка стратегии продаж

Взаимодействие с разработчиками происходит как формальное, так и неформальное. Основным формальным документом, который является результатом работы Product Manager и определяет продукт для разработчиков и является MRD - Marketing Requirements Document.

MRD описывает разрабатываемый продукт или новую версию продукта, с точки зрения заказчика. Заказчик - это будущий потребитель продукта и это может быть как человек, который купит коробку с программой в магазине, так и другой отдел той же компании. MRD нужен, чтобы разработчики получили представление о продукте, необходимой функциональности и могли начать разработку (здесь под разработкой понимается весь комплекс работ - дизайн, архитектура, кодирование, тестирование и все остальное, что разработчики считают нужным туда включить).

Ну то есть MRD - это документ при помощи которого Product Manager (человек представляющий заказчика и, в теории, знающий что тому нужно) пытается донести нужды заказчика до разработчиков.

Теперь попробуем описать какие разделы должен включать MRD. Для удобства я попытаюсь сразу после описания соответствующего раздела давать пример.

MRD представляет из себя документ, в общем, свободного формата. Основная аудитория MRD - это:

Разработчики
Разработчикам MRD необходим для понимая того что же именно нужно написать.
Высшее руководство
Ну, во-первых, начальство конечно должно быть в курсе что собственно делается ;-) Во-вторых, MRD - это документ, являющийся обоснованием для получения ресурсов (материальных и людских), если их не хватает.
Заказчик
Заказчику MRD предоставляется в составе более широкого пакета документов, для утверждения. В случае возникновения споров по поводу наличия или отсутствия той или иной функциональности MRD является документом, который помогает их разрешению.

Помня о нашей аудитории и целях создания документа, опишем его составные части:

MRD для нового продукта "Феликс"

Цель создания продукта или выпуска очередной версии.
В данном разделе описывается проблема, существующая у потенциальных или реальных заказчиков и объясняется, как именно продукт или новая версия продукта эту проблему устранит. Это очень важный раздел, он должен сравнительно кратко объяснить что же именно предстоит сделать.

Пример: Не все люди достаточно хорошо могут считать "в уме". Особенно плохо это получается у людей, если числа являются не целыми и достаточно большими. Во многих магазинах существует проблема ошибок кассиров, которые, высчитывая цену покупок "на бумажке", часто ошибаются. Это приводит к недовольству покупателей (если кассир ошибается не в их пользу) или же к потерям самого магазина. Недовольные покупатели могут перестать приходить в этот магазин и, таким образом, также снизить доходы. Проблема очень велика и статистика показывает, что расходы магазинов связанные с потерями при арифметических подсчётах, увеличиваются с каждым годом:

Год

Потери

2004

$200млн.

2005

$300млн.

2006

$400млн.

Продукт "Феликс" предназначен для того, чтобы помочь магазинам справиться с описанной проблемой. Он будет представлять из себя небольшую программу, которая может быть запущена на мобильном телефоне кассира и поможет ему подсчитывать суммы, которые раньше ему приходилось считать на бумаге.
Описание того, какой результат должен быть достигнут и в какие сроки.
Здесь необходимо описать что именно должно получиться (web-сервис, java-приложение, некоторый документ, который описывает что-то, некоторое устройство, обладающее определёнными характеристиками). Также в этом разделе обычно указывается желаемый (с точки зрения заказчика) срок получения продукта. Хочу специально отметить, что это не срок, за который продукт будет сделан. Это всего лишь желаемый срок. MRD проходит в своём развитии много итераций и реальные сроки исполнения в нем обычно не указываются. Заказчику сроки исполнения обычно предоставляются в других документах. Тем не менее указать желаемое время (например некоторое важное с маркетинговой точки зрения событие) здесь вполне возможно.
Пример: Поскольку по результатам исследований выяснилось, что большинство кассиров в магазинах пользуется мобильными смартфонами с установленной на них операционной системой компании Microsoft - Windows Mobile 6.0, то Феликс должен представлять собой программу работающую под управлением этой и последующих версий ОС Windows Mobile 6.0. В сентябре следующего года ожидается всемирная выставка Кассир-2008 в Лас-Вегасе и первую версию программы очень желательно иметь к этому времени, для того чтобы мы могли разрекламировать её во время выставки.
Описание функциональных возможностей продукта.
Данный раздел собственно и составляет самую большую часть MRD - в нем описывается какие именно функции должен выполнять продукт. В зависимости от самих функций, квалификации Product Manager и принятых в компании правил, раздел может быть более или менее подробным. В частности, подробные сценарии использования (use cases) каждой из функциональных возможностей могут присутствовать, а могут и нет. Также MRD может включать или не включать в себя внешний вид пользовательского интерфейса. В любом случае, сценарии использования и внешний вид пользовательского интерфейса обычно появляются на той или иной стадии разработки и обычно являются дополнениями к MRD, поскольку дают более полное представление о продукте.

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

Пример: Феликс должен обладать следующими возможностями:

Сложение действительных чисел, при помощи стандартных правил сложения, описанных в учебнике Г.М. Фихтенгольца
Приоритет: очень важно
Вычитание действительных чисел, при помощи стандартных правил вычитания
Приоритет: очень важно
Умножение действительных чисел
Приоритет: очень важно
Деление действительных чисел
Приоритет: очень важно
Скорость выполнения операций не должна быть больше 10 секунд на одну операцию
Приоритет: очень важно
Программа установки, выполненная по стандартам Windows Mobile 6.0
Приоритет: очень важно
Drag&Drop
Приоритет: очень важно
Plug&Play
Приоритет: очень важно
Возможность распечатывать результаты
Приоритет: очень важно
Наличие подробной документации по всем функциям программы
Приоритет: очень важно

Заметили ли вы некоторые странности в последнем примере? Что за удивительная функция Drag&Drop? А что такое Plug&Play? Какое отношение они имеют к программе "Феликс"? А может быть есть ещё какие-то странные требования? А почему собственно приоритет ВСЕХ функций поставлен как "очень важно"? Частенько Product Manager формулирует свои требования не достаточно чётко или само требование не кажется особенно осмысленным. Поэтому составление MRD часто требует нескольких итераций, так что каждая следующая делает этот документ более "внятным".
Для того чтобы уменьшить количество этих итераций, описание функциональных возможностей также иногда делят на части:

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

Такие функциональные возможности, которые предложил Product Manager для программы Феликс - Drag&Drop и Plug&Play возможно являются следствием того, что он бездумно пошёл на поводу у рекламы и просто включил в список пару "красивых" с его точки зрения фраз.

Составление MRD требует от Product Manager довольно большой работы, анализа конкурентов и ситуации на рынке, а также, иногда, понимания технической стороны вопроса.
Но, при наличии грамотно составленного MRD, взаимодействие заказчиков и разработчиков сильно улучшается и снимаются возможные проблемы, так что по крайней мере старая шутка по качели станет на один шаг короче:

С наступившим!

2008-01-01T12:55:00.000+03:00

С наступившим, всего самого лучшего в новом году! Успехов, удачи, здоровья, всего!

Музей истории компьютера

2007-12-14T18:45:00.000+03:00

Музей истории компьютера, совместно с YouTube, открыли канал, на который будут выкладываться видео выступлений, происходящих в музее.

Сейчас там лежит 23 различных видео, ну и думаю будут ещё :-)

Требования: возраст до 35 лет

2007-12-06T20:37:00.000+03:00

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

Ну и в качестве подготовки просмотрел вакансии некоторых популярных и не очень популярных компаний. В качестве disclaimer, хочу сказать что я конечно смотрел не все вакансии, а некоторые, и при этом "программистские" - С++ программист, java программист и тому подобные. Ну и список компаний, конечно достаточно произвольный, просто те что так сказать "на слуху".

Результаты довольно интересные:

Компании, не устанавлювающие никаких ограничений по возрасту

Компании, устанавливающие ограничения

Крок - в среднем ограничение возраста 23-35 лет
Результаты поиска в группе форумов RSDN ( Программирование :: Работа):
"По запросу '"возраст до" | "Возраст до"' найдено документов: 51".

Ну что тут сказать. Конечно эта статистика не полна и спорна. Тем не менее видно, что возрастных ограничений не так уж и много. По каким причинам возникают возрастные ограничения для программистов?

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

Рассмотрим эти причины в обратном порядке.

Молодая команда

Если в компании всем людям по 20 лет, то им не хочется нанимать 40-летнего коллегу. Скучно, страшно, неинтересно, ритмы другие. Некоторое время назад практически вся программистская индустрия в России состояла из очень молоых людей и сответственно приобщались к ней молодые. Во-первых потому что других особо и не было, во-вторых по уже изложенным причинам. Но молодость - это недостаток который быстро проходит. И поэтому со временем происходит (и уже произошло) взросление команд и соответственно возрастные рамки расширяются.

"Не хотим брать неудачников"

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

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

Поэтому мне думается, что такое объяснение - плохой повод для введения ограничений по возрасту.

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

Экономия

Ну тут-то мне кажется ничего особо говорить не надо? Под видом двух предыдущих причин попытаться нанять дешёвых людей делать дорогую работу. И все тут.

Заключительные мысли

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

Вообще большинство известных мне случаев приёма или не приёма на работу людей "после 35" определялись в конечном итоге исключительно профессиональными качествами, а вовсе не возрастом.

Here comes another bubble ...

2007-12-05T19:57:00.000+03:00

Небольшое видео про Web 2.0 бум :-) Смешно, особенно потому что очень правдиво.

P.S. Если по каким-то причинам не получается посмотреть видео, то вот ссылка:
http://dev.podesk.com/guest.php/post/2007/12/04/Here-Comes-Another-Bubble-lyrics

Here Comes Another Bubble lyrics sent by guest

Успех? Терпение!

2007-11-27T10:34:00.000+03:00

Довольно давнее время назад мне попалась на глаза статья Eric Sink, под названием "Career Calculus". Статья показалась довольно интересной, и я даже перевёл её на русский язык.

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

С другой стороны, недавно возник такой вопрос - насколько важен для успеха такой фактор как талант? Многие люди, выбирающие работу спрашивают себя: "А что, если у меня нет к этому способностей?"

Мне кажется что вопросы перекликаются - для того чтобы добиться успеха необходимы какие-то предусловия, что-то заложенное в нас при рождении или мы сами "кузнецы своего счастья"?

Действительно ли способности так важны? Мне кажется влияние способностей сильно преувеличено. Более того, ссылка на "отсутствие способностей" очень часто является просто поводом "увильнуть" от неприятной для человека работы.

Конечно, способности оказывают влияние, вопрос только какое именно?

Мне кажется существенно большее влияние на "успешность" оказывает упорство и трудолюбие. Заметим, при этом я не говорю о "великих", хотя и они, в большинстве своём, были большими тружениками. Я говорю о "крепких середняках", людях вполне добившихся успеха, но не о Биллах Гейтсах, Ньютонах или Пеле.

Для достижения "нормальных" результатов в спорте, программировании и даже музыке или рисовании необходимо только одно - упорство. Все это лестница и талантливые просто начинают с более высокой ступеньки. Конечно, Леонардо Да Винчи большинство из людей не станет, но научиться рисовать "приемлемо" вполне возможно. (между прочим Леонардо, который, как известно, испытывал свои силы практически во всех областях наук и искусств, говорил "“Счастье приходит к тому, кто много трудится”; неизвестно, добился бы он таких успехов, если бы "не очень" старался)

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

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

Ещё вопросы

2007-11-09T12:56:00.000+03:00

Некоторое время назад я написал небольшой пост под названием "Хорошие вопросы", в котором рассказывал про вопросы, которые, как мне кажется, стоило бы задавать на собеседованиях. Там же были некоторые мысли почему именно подобные вопросы стоит задавать, а другие не стоит.

С тех пор уже прошло довольно много времени и у меня появились ещё вопросы, которые вполне можно добавить в тот список.

Что такое тип (предложено Iv) ?
Что такое тестирование? (взято из http://www.techinterviews.com/?p=64)
Почему нельзя запустить под Windows программу для Macintosh? (имеется ввиду без применения специальных ухищрений; впрочем ухищрения тоже можно обсудить)
В чем разница между "оперативной памятью" и "жестким диском"?
Что такое язык программирования? Зачем нужна подобная сущность? (в обсуждении можно коснуться и ассемблера и машинных кодов)

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

Вопрос такой: 2^8 - это сколько?

Нужен ли такой вопрос и что именно он проверяет - это отдельная беседа. Но у меня на эту тему возник другой вопрос:

6. А почему собственно степени двойки так важны? Почему проверкой вменяемости программиста является "отскакивающий от зубов" ответ на вопрос сколько будет 2^8? А не скажем 3^7 :-)

И как и раньше хочу сказать: цель вопросов - спровоцировать разговор на "базовые" темы, а не получить "правильный" ответ.

Распознавание шрифта

2007-10-18T01:12:00.000+04:00

Иногда возникает необходимость узнать какой шрифт был использован в той или иной картинке.

Задача казалось бы довольно простая - раз уж у нас существуют средства, позволяющие распознавать сам текст с картинки, то уж распознать шрифт, которым этот текст написан не должно быть очень сложно.

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

Для решения есть несколько более или менее автоматизированных средств:

WhatTheFont - web-приложение, которое позволяет загрузить картинку и автоматически пытается определить шрифт. Изображение нужно сначала специальным образом подготовить (подробные инструкции есть на сайте)
Identifont , ITC Fonts, Fonts.com - содержат небольшую "экспертную" систему, которая задаст некоторое количество вопросов про интересующий шрифт и выдаст список наиболее подходящих шрифтов
FontMatch - windows приложение, позволяющие загрузить изображение буквы и пытающаяся найти среди имеющихся на компьютере шрифтов подходящий
Kleptomania - отличное windows-приложение, предназначенное в основном для того, чтобы копировать текст из окон, которые этого не поддерживают. Также умеет распознавать и шрифт, которым написан текст.
FineReader или другая полноценная программа распознавания текста. Все в них хорошо, кроме того что при их использовании не покидает ощущение стрельбы из пушки по воробьям.

Мой выбор - (4) - Kleptomania - самая удобная, быстрая и к тому же бесплатная программа.

P.S. Ну если честно, то в итоге все равно в Word-е глазами на шрифты смотрел и вручную сравнивал :-) На всякий случай ...

Производительность XSLT

2007-10-04T16:49:00.000+04:00

XSLT не очень "быстрый" язык. Разные XSLT процессоры работают по разному, и пользуются разными методами оптимизации.

На практике довольно часто встречаются ситуации, когда одна и та же XSLT программа быстро работает при использовании одного процессора и медленно при использовании другого.

В XSLT существуют потенциально медленные конструкции, при этом разные процессоры могут с разной скоростью исполнять разные инструкции, поскольку по-разному оптимизированы.

В этой заметке я попытался собрать некоторые наблюдения по поводу производительности XSL.

XSLT процессор и ОС

Иногда может показаться так, что один и тот же XSLT процессор по разному работает на под разными ОС.

Убедитесь что вы действительно используете один и тот же процессор и одну и ту же версию, иначе все ваше сравнения окажутся пустой тратой времени.

Про переменные

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

count

Ф-я count вычисляет количество узлов в наборе и работает иногда чрезвычайно медленно. Если есть необходимость её использовать, то старайтесь вызывать её минимальное количество раз и помещать вычисленное значение в переменную.

preceding:: и другие

Использование preceding и других "осевых" функций (preceding-sibling, following, following-sibling) может существенно замедлить XSL преобразование, поэтому необходимо постараться от них избавиться.

Часто preceding и preceding-sibling используются для организации группировки или выборки уникальных элементов. Вместо этого можно пользоваться методом Мюнха(xsl:key + generate-id()).

//

Использование '//' для поиска также может сильно замедлить преобразование, особенно в случае большого файла, с большим количеством узлов. Здесь, также как и в случае группировки, стоит подумать об использовании xsl:key.

Проход по узлам

Старайтесь осуществлять "проход" по коротким спискам.

Использование ключей

Ключи (элемент xsl:key и функция key) могут очень сильно улучшить производительность XSL программы, особенно если в ней производятся "большие" поиски.

В зависимости от реализации использование элемента xsl:key приводит к созданию XSL процессоров внутреннего индекса, за счёт чего достигается очень быстрый доступ к соответствующим узлам.

Использование сокращённого вычисления (short-circuiting)

В XSL, как и во многих других языках программирования вычисление булевых выражений осуществляется при помощи сокращённого вычисления. Это значит что вычисление прекращается, как только ясен результат. Например в выражении [1 OR (всё-что-угодно)] значение выражения 'всё-что-угодно' вычисляться не будет, поскольку ясно, что общий результат от этого не изменится.

А раз так, то стоит в логических вычислениях (xsl:if, xsl:when) ставить в начало те выражения, которые требует меньше времени для вычисления.

Не стоит полагаться на xsl:message

Очень часто мы пользуемся в своей работе "отладочной печатью". В случае XSL ф-ю печати выполняет элемент xsl:message. Этот элемент тем не менее не совсем прост. Дело в том, что он нарушает необходимое в функциональном языке (а XSL - функциональный язык) свойство отсутствия побочных эффектов. На самом деле порядок вывода xsl:message не обязательно будет таким, как нам кажется, он может зависеть от используемого XSL процессора. Поэтому для отладки, на мой взгляд, лучше пользоваться встроенными средствами трассировки, имеющихся практически во всех процессорах.

И напоследок

Каждый XSLT процессор работает немного по-своему. Совершенно необходимо тестировать подготовленное XSLT преобразование именно на том процессоре, который будет работать в реальной версии продукта.

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

Также, помочь определить проблемные места программы на XSLT может профилирование, то есть измерение времени выполнения определенных участков кода. Практически все современные IDE для работы с XML и XSLT (например Altova XMLSpy, Stylus Studio, oXygen XML) предоставляют также средства профилирования.

Что ещё почитать про производительность XSLT

Предложения разработчиков процессора Xalan
Советы от Microsoft
Список советов по улучшению производительности XSLT из XSLT FAQ (в том числе от Michael Key)
Немного теории: Michael Key: XSLT and XPath Optimization.

Enterprise улетает с Альтаира?

2007-09-24T10:48:00.000+04:00

Недавние мои собственные посты на темы "portable applications" и по поводу "носителей информации", а также комментарий Morph натолкнули меня на следующие размышления.

Действительно, сейчас наблюдаются несколько тенденций, которые тянут "персональные данные" в противоположные стороны.

Все своё ношу с собой

С одной стороны, portable программы получили большое развитие. Все больше программ становятся независимыми от реестра (в windows мире), поскольку хранят свои настройки в собственных конфигурационных файлах (и .NET только способствует этому). А раз так, то они по сути все ближе приближаются к portable миру. Flash-ки и внешние USB-винчестеры становятся все более ёмкими и надёжными, возможность полностью носить с собой всю свою рабочую "среду" является все более и более реальной (например "нафаршированная" флэшку n-Key Flash).

Omnia mea mecum porto

:-) Да, на самом деле второй заголовок - это первый на латыни. Но вот история исходного выражения говорит нам о том, что в дни завоевания персами греческого города Приены за толпой беглецов, еле тащивших на себе тяжёлое имущество, спокойно шёл налегке мудрец Биант. Когда его спрашивали, где его вещи, он, усмехаясь, говорил: «Все, что имею, всегда ношу при себе». На самом деле он вероятно имел ввиду, что ум, знания и внутренняя сила человека гораздо важнее, чем какие-то конкретные вещи и материальные накопления.

Сейчас есть возможность не носить с собой ничего. Google, а сейчас и многие другие компании создали в Сети такую среду, что многим людям достаточно иметь компьютер, подключенный к интернет, а все необходимы им программы и данные они могут найти в сети. Вся почта в gmail, все документы в Google Docs или подобных системах.

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

Большой брат

Крупные компании исповедуют конечно же свой путь. Они запрещают подключать флешки, пользуются внутрикорпоративной почтой и так далее. Закон Сарбейнс-Оксли и все такое.
В большой компании не нужен "персональный компьютер". любой сотрудник может подойти к любому компьютеру и работать( ну конечно это натяжка, но ведь они к этому стремятся, это так сказать недостижимый идеал). [большие компании бывают разные и я здесь конечно говорю в основном НЕ про компании-производители программного обеспечения].

Тем не менее, мне кажется что на самом деле большие компании давно идут по пути "централизации" информации. Ведь нет большой разницы между тем, что у обычного пользователя почта хранится в Google или на корпоративном Exchange сервере. Разница есть с точки зрения компании - хранится ли информация у самой компании или у "чужой" компании. А вот с точки зрения человека разницы нет - его данные хранятся не у него в обоих случаях.

Размышления

И что же мы видим? Мне видится два момента.

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

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

В 1975 году появился компьютер Altair, что ознаменовало собой начало эры персональных компьютеров. Говорят, что название компьютера было придумано дочерью технического редактора журнала "Popular Electronics" Леса Соломона, поскольку в тот день корабль Enterprise из популярного сериала "Звездный путь" должен был направится именно на Альтаир. Прошло 32 года. Эра персональных компьютеров закончилась? Enterprise улетает с Альтаира?

amazon.com

2007-09-18T13:29:00.000+04:00

Блог High Scalability опубликовал интересную статью о внутренней архитектуре amazon.com и о некоторых принципах организации работы в amazon (в частности, там есть немного про премии).

P.S. На том же сайте есть подобные описания архитектуры google, youtube, wikipedia и других по настоящему больших проектов.

17458907.48319b4763d4aa2700c0fda3363b9fab.1190107741.d9c1ec9c770af938959863dd60b588c0

Носители информации: несколько мыслей

2007-09-16T14:50:00.000+04:00

Недавно мой КПК упал на асфальт. У меня Dell Axim X50v. Довольно приличная машинка - вполне удовлетворяет всем моим потребностям, которые ограничиваются, если честно, адресной книгой, калькулятором и программкой-хранителем паролей.

Так вот он упал на асфальт. Не очень-то с большой высоты - я выходил из машины, КПК висел на поясе, я обо что-то задел, машинка отсоединилась и упала с высоты сидящего в машине человека. КПК был конечно же в чехле, так что удар был совсем не сильный. У меня подобные падения и раньше случались, но тем не менее ни к каким неприятным последствиям не приводили.

Но в этот раз везение кончилось. Теперь при включении КПК стал выдавать сообщение о какой-то "Memory error". И дело кончилось тем что мне пришлось произвести полную его перезагрузку. Кто пользовался КПК знает что полная перезагрузка подразумевает приведение машинки в девственно-чистое состояние, при котором исчезают все установленные программы и данные (ну кроме данных которые записаны на flash карту).

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

Я "много думал" :-) Сначала мне вспомнились многочисленные виды носителей информации, придуманные человечеством за всю историю его существования. О них я писал в предыдущем посте: "Носители информации: краткая истрия в картинках". А потом я начал анализировать чего мы добились и какой ценой.

Современные носители - характеристики

Объем: к настоящему времени мы придумали такие способы сохранить информацию, что информацию, содержащуюся в миллионе книг можно уместить в устройстве, размером с небольшой дипломат.
Поиск: И к тому же при помощи современных средств хранения информации можно ещё и найти что-нибудь в этом море информации.
Универсальность: мы можем сейчас хранить существенно больше видов информации чем раньше. Нам теперь доступны возможности хранения видео и звука, что было затруднительно раньше.
Простота репликации: благодаря современным способам хранения информации, её копирование стало чрезвычайно простым и дешёвым, и это возможно самое важное достижение, без которого все остальные были бы не очень ценны из-за чрезвычайного снижения надёжности носителей информации (см. ниже).

Однако все имеет свою цену.

Современные носители - цена

Современные носители информации таковы, что для извлечения информации требуется потратить существенно больше энергии, чем раньше. Для считывания информации с бумаги, с глиняной таблички или поверхности камня необходимо было лишь небольшое количество света и некоторые затраты, которую требуются человеку для осуществления самого процесса чтения. Сейчас, чтобы считать информацию, находящуюся на DVD Диске или на карте памяти требуется специальное устройство, тогда как все остальные расходы конечно сохраняются.
Мы платим за все плюсы современных средств хранения информации очень небольшой их надёжностью, по сравнению со средствами хранения, которые были у нас раньше. Наскальные рисунки сохранились многие тысячи лет, тоже можно сказать о глиняных табличках, берестяных грамотах и египетских папирусах. Возьмите CD 15-летней давности ...

Разное

Мы пытаемся решить проблему надёжности бесконечным копированием информации (созданием "резервных" копий), потому что на самом деле другого способа нет
Уменьшение надёжности , как мне кажется является вполне естественным - чем больше информации мы умещаем на небольшой площади тем менее избыточным, а значит менее надёжным становится наше хранилище
Именно из-за чрезвычайного уменьшения надёжности концепция "безбумажного офиса" до сих пор окончательно не реализована
Мы заплатили за все современные возможности носителей информации увеличением цены (большими затратами энергии) и уменьшением надёжности. Мне кажется это слишком дорого, чем-то конечно нужно платить, но хватило бы либо цены, либо надёжности.
Революция случится тогда, когда будет создан носитель информации имеющий современные характеристики и хотя бы такой же надёжный как бумага

Вот такие вот мысли. Выводов никаких нет ...

Носители информации: краткая история в картинках

2007-09-12T13:13:00.000+04:00

Наша цивилизация немыслима в её сегодняшнем состоянии без носителей информации. Наша память ненадёжна, поэтому достаточно давно человечество придумало записывать мысли во всех видах.

Носитель информации - это любое устройство предназначенное для записи и хранения информации.

Примерами носителей могут быть и бумага, или USB-Flash память, также как и глиняная табличка или человеческая ДНК.

Информация тоже бывает разная - это и текст и звук и видео. История носителей информации начинается довольно давно ...

Камни и стены пещер - палеолит (до 40 до 10 тыс. лет до нашей эры)

Первыми носителями информации были, по всей видимости, стены пещер. Наскальные изображения и петроглифы (от греч. petros - камень и glyphe - резьба) изображали животных, охоту и бытовые сцены. На самом деле точно неизвестно, предназначались ли наскальные рисунки для передачи информации, служили простым украшением, совмещали эти функции или вообще нужны были для чего то ещё. Тем не менее это самые старые носители информации, известные сейчас.

Глиняные таблички - 7-й век до нашей эры

На глиняных табличках писали пока глина была сырой, а затем обжигали в печи.

Именно глиняные таблички составили основы первых в истории библиотек, наиболее известной из которых является библиотека Ашшурбанипала в Ниневии (7 век), которая насчитывала около 30 тысяч клинописных табличек.

Восковые таблички

Восковые таблички - это деревянные таблички, внутренняя сторона которых покрывалась цветным воском для нанесения надписей острым предметом (стилосом). Использовались в древнем Риме.

Папирус - 3000 лет до нашей эры

Папирус - писчий материал получивший распространение в Египте и во всем Средиземноморье, для изготовления которого использовалось растение семейства осоковых.

Писали на нем при помощи специального пера.

Пергамент - 2 век до нашей веры

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

Популярности пергамента способствовало то, что на нём (в отличие от папируса) есть возможность смыть текст, написанный растворимыми в воде чернилами (см. палимпсест) и нанести новый. Кроме того, на пергаменте можно писать с обоих сторон листа

Бумага - 1-й или начало 2 века нашей эры

Предполагается что бумага была изобретена в Китае в конце первого или начале второго века нашей эры.

Широкое распространение получила благодаря арабам только в 8-9 веках.

Береста - широкое распространение с 12 века

Берестяные грамоты использовались в Новогороде и были открыты учеными в 1951 году.

Тексты берестяных писем выдавливались с помощью специального инструмента — стилоса, изготовленного из железа, бронзы или кости.

Перфокарты - появились в 1804 году, запатентованы в 1884 году

Появление перфокарт в основном связывается с именем Германа Холлерита, который применил их для проведения переписи населения в США в 1890 году. Тем не менее первые перфокарты были созданы и использованы существенно раньше. Жозеф Мари Жаккард использовал их для того чтобы задавать рисунок ткани для своего ткацкого станка ещё в 1804 году.

Перфоленты - 1846 год

Перфолента впервые появилась в 1846 году и использовалась для того, чтобы посылать телеграммы

Магнитная лента - 50-е годы

В 1952 году магнитная лента была использована для хранения, записи и считывания информации в компьютере IBM System 701.

Далее магнитная лента получила огромное признание и распространённость в форме компакт-кассет.

Магнитные диски - 50-е годы

Магнитный диск был изобретен в компании IBM в начале 50-х годов.

Гибкий диск - 1969 год

Первый, так называемый, гибкий диск был впервые представлен в 1969 году.

Жесткий диск - настоящее время

Вот мы и добрались до современности.
Жесткий диск изобретен в 1956 году, но продолжает использоваться и постоянно совершенствоваться.

Compact Disk, DVD - настоящее время

На самом деле CD И DVD это очень близкие технологии, отличающиеся не столько типом носителя, сколько технологией записи

Flash - настоящее время

Естественно здесь перечислены далеко не все придуманные и использованные человечеством носители информации. Часть видов носителей опущена специально (CD-R, Blue Ray, магнитные барабаны, лампы), а часть конечно просто забыта. Во всех ошибках или неправильных описаниях, виноват конечно же я,был бы благодарен за любые дополнения и уточнения.

Благодарности

При подготовке текста были использованы источники:

Википедия (как русская, так и английская)
Советский Энциклопедический Словарь
Берестяные грамоты и письма средневековой Руси
History of Data Storage
University of Michigan Papyrus Collection
IBM Storage Photo Album
Колесников Евгений Алексеевич. Технико-исторические заметки.

Несколько интересных блогов

2007-09-12T11:37:00.000+04:00

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

А в этом смысле, как многие вероятно уже знают, сейчас стали популярны "Вьетнамские эксперименты" Дмитрия Давыдова. По следам этих экспериментов, насколько я понимаю, и родился сервис Блог-Фильтр, который собственно и предназначен для более или менее автоматизированного проведения "вьетнамских экспериментов.

Вот соответственно и я решил поучаствовать в его работе, для чего выкладываю сюда ссылки на блоги из блог-фильтра, которые мне кажутся интересными:

1) Блог Дмитрия Давыдова - автора "вьетнамского эксперимента"
2) Блог успешного web-разработчика
3) Блог интернет-разработчика

Portable Applications: джентльменский набор

2007-09-05T16:00:00.000+04:00

Некоторое время назад узнал про новое значение термина "portable application". Это раньше мне казалось, что portable - это такая программа, код которой можно без больших усилий переносить между операционными системами - например с Windows на Solaris. Современная трактовка, более известная непрограммистской публике, другая.

Portable Applications - это такие приложения, которые для работы не требуют инсталляции - достаточно скопировать файлы самого приложения и, может быть, настройки.

Таким образом программы можно носить с собой на flash-ке или на USB-винчестере.

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

Вот что у меня всегда с собой:

Файловый менеджер: TotalCommander. В религиозной войне между приверженцами TC и Far я принадлежу лагерю любителей TC. Поэтому и сам файловый менеджер и многочисленные используемые мной плагины у меня всегда со мной. Благодаря этому его никогда не нужно перенастраивать под себя - один раз настроил и всегда готов к работе.
Instant Messaging:

Miranda: тут у меня и ICQ и MSN и Gtalk и AIM - все instant messengers, которыми я пользуюсь

Skype: пока что я не увидел толкового плагина skype для миранды, поэтому skype стоит сам по себе. Поставил, как только понял что можно заставить его быть "portable"

Browsers:

Portable Firefox - браузер которым я пользуюсь практически постоянно, естественно достаточно нафарширован плагинами. Очень удобно пользоваться "запоминалкой паролей" и вводить ничего не надо и на самом деле твои пароли всегда с тобой.

Opera USB - запасной браузер.

WinScp - SFTP клиент; он правда хранит настройки в registry, но я их экспортирую
Утилиты от Mark Russinovitch

Autoruns

DbgView

ProcessExplorer

ProcessMonitor

Orca - кто разрабатывал инсталляционные процедуры для Windows Installer, тот знает :-)
Araxis Merge - лучшая, на мой взгляд, Diff/Megre программа. На самом деле тоже хранит настройки в registry, но с этим можно смириться
EditPlus - "легкий" текстовый редактор с подсветкой синтаксиса. Кнопка F4 у меня в TotalCommander настроена именно на него
OllyDbg - отладчик :-)
TheBrain - программа - хранилище заметок, закладок, и так далее. Отличается тем, что хранит информацию не в стандартном "деревянном" виде, а в виде графа, так что к одной и той же заметке/закладке можно придти разными путями.

Вот таким вот образом. Очень удобно и я уже довольно давно забыл про то что настраивать программы нужно на каждом компьютере.

17458907.48319b4763d4aa2700c0fda3363b9fab.1188990934.a3319c942a5192f6e66ca91f6f9e104c

Архивы в сети

2007-08-31T14:55:00.000+04:00

В Сети помимо порнографии есть и ещё кое-что :-) В частности, выложены в сеть архивы многих выдающихся учёных.

Программистское

Подборка статей классиков программирования (Вирт, Ершов, Хоар, Кнут, Бэкус, Наур и др.)
Подборка классических работ по версии ACM: http://www.acm.org/classics

И не только

Архив работ Карла Фридриха Гаусса (осторожно - латынь!)
Архивы Российской Академии Наук (В.И. Вернадский, С.И. Вавилов и другие)
Работы Чарльза Дарвина

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

Во-первых о том, что к сожалению не вполне ясно насколько эти архивы точны. Уж слишком легко изменить информацию в Сети. Ну конечно подменой занимались всегда - совершенно неважно в какой "информационной среде" это происходит. А с другой стороны согласитесь - осуществить подмену цифровой информации существенно проще, чем приходилось служащим в министерстве правды.

А во-вторых о том, не случится ли что-то с этими сайтами в будущем, не исчезнут ли они? Каждый раз хочется все к себе скачать :-)

Ну в любом случае пока что вся информация на месте, ссылки работают, так что у нас всегда есть возможность посмотреть на первоисточники и почитать великих...

Про типы

2007-08-19T12:54:00.000+04:00

В Блоге Тру Программиста появилась подборка статей, посвящённых типам данных. Всем интересующимся рекомендуется к прочтению.

Все описанное в статьях (как тех на которые я ссылался, так и первоисточниках имени Chris Smith и Luca Cardelli), написано на довольно высоком уровне. Мне же кажется, что очень важным моментом здесь является "качественное" понимание, объяснение, так сказать "на пальцах". Потому что без подобного понимания знание фактов и определений скорее является следованием "культу карго", чем настоящим знанием.

Итак, что же такое типы и зачем они нужны?

Типы данных пришли в программирование из математики. В математике же, как и многие другие понятия они появились по необходимости.

Как известно математики часто проводят в своих рассуждениях чёткое различие между элементами, множествами элементов, функциями и так далее. Для новой переменной, используемой в первый раз, математик определяет "тип", например: "Пусть f - это функция действительного переменного". Часто в книгах (обычно во введении и предисловии) также даются подобные определения: "В дальнейшем для множеств будут использоваться прописные буквы". Эти определения являются не более чем "помощниками" для читателя, позволяют ему быстрее ориентироваться в дальнейшем тексте.

Представители логики и теории множеств предпочитали не иметь дело с переменными различных "типов". Однако, такая необходимость появилась весной 1901 года, когда, во время работы над фундаментальным трудом "Principia Mathematica" известный английский математик и философ Бертран Рассел сформулировал так называемый парадокс Рассела:

"Пусть S - это множество всех множеств, которые не содержат себя в качестве элемента. Содержит ли S само себя?"

Любой ответ, данный на этот вопрос практически мгновенно приводит к противоречию. Данный парадокс можно также переформулировать несколькими более "жизненными" способами:

Деревенскому брадобрею приказали «брить всякого, кто сам не бреется, и не брить того, кто сам бреется», как он должен поступить с собой?
В одной стране вышел указ: «Мэры всех городов должны жить не в своем городе, а в специальном Городе мэров», где должен жить мэр Города мэров?
Некая библиотека решила составить библиографический каталог, в который входили бы все те и только те библиографические каталоги, которые не содержат ссылок на самих себя. Должен ли такой каталог включать ссылку на себя?

Решение этого парадокса, предложенное Расселом носит название "теории типов" и заключается в том, что каждой логической или алгебраической переменной приписывается "тип", который определяет, обозначает ли она [переменная] элемент, множество, множество множеств и так далее. Далее, Рассел постулировал, что любое утверждение вида" x является элементом из y" грамматически осмысленно лишьтогда, когда x - переменная типа элемент, а y - переменная типа множество или x - переменная типа множество, а y - переменная типа множество множеств и так далее. Любое утверждение, не удовлетворяющее этому правилу считается бессмысленным - вопрос о его истинности или ложности просто не существует, оно представляет собой просто набор букв.

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

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

Особенностями понятия типа являются:

Тип определяет класс значений, которые могут принимать переменная или выражение
Каждое значение принадлежит одному и только одному типу
Тип значения константы, переменной или выражения можно вывести либо из контекста, либо из вида самого операнда, не обращаясь к значениям, вычисляемым во время работы программы
Какой операции соответствует некоторый фиксированный тип операндов и некоторый фиксированный (обычно тот же самый) тип результата. (операции, обозначаемые одним и тем же символом, но производимые над различными типами операндом считаем разными)
Для каждого типа свойства значений и элементарных операций над значениями задаются при помощи аксиом.

Таким образом знание типа, позволяет обнаруживать в программе бессмысленные конструкции и предотвращает множество ошибок.

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

Использованные материалы:

Russel's Paradox
Парадокс Рассела - Википедия
Luca Cardelli. Type systems.
К. Хоор "О структурной организации данных" из книги У. Дал, Э. Дейкстра, К. Хоор "Структурное программирование", Москва, Мир, 1975

Реальное рабочее время

2007-08-04T13:03:00.000+04:00

Меня продолжает сильно интересовать проблема оценки сроков проекта. В этой связи я наконец добрался до книги Steve McConnel Software Estimation: Demystifying the Black Art, которая в русском переводе имеет совершенно удивительное название "Сколько стоит программный проект". (на самом деле объяснить название конечно можно, поскольку в содержании книги сроки, затраты или рабочее время считаются более или менее взаимозаменяемыми понятиями).

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

В книге описаны различные способы оценки сроков (или затрат) на выполнение проектов, но меня заинтересовало вот что.

В какой-то момент любые, даже самые сложные и "научные" способы оценок сводятся к вопросу: "А тебе сколько времени будет нужно для того, чтобы сделать вот это?". И в этот момент называется число (или диапазон, или лучший худший и наиболее вероятный вариант - неважно).".

Насколько это число соответствует действительности - неважно, лучшего у нас все равно нет. Однако важным является то, учитывает ли это число время, проведённое на работе, но при этом потраченное на "нерабочие дела" - интернет, кофе, перекуры и так далее.

В связи с этим какое-то время назад я организовал на RSDN голосование поэтому поводу. Вот вопрос, который я задавал и результаты голосования:

Вот такие результаты. Думаю, что при планировании очень стоит помнить про то, что не все время, проведённое на работе, действительно уделяется работе.

Замечания

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

"Подобные подсчеты бессмысленны". Бизнес сторона программирования требует выдачи сроков. Более того, часто невозможно даже давать сроки по Steve McConnel - при помощи диапазонов. И человеку, который должен составить оценку волей или неволей приходится выдавать прогноз. И лучше если у него есть понимание того, что выданная оценка скажем в 5 часов рабочего времени - это в реальности два рабочих дня.
"Настоящий программист может думать о работе и дома и во время отдыха, поэтому непонятно что считаем". Действительно, это так. И действительно это не особенно то и подсчитаешь. Программа подсчёта рабочего времени может подсчитать сколько времени у меня на экране была открыта Visual Studio, но вряд ли догадается, что я в это время думал про то, как здорово понырял в красном море. Тут мой ответ таков - лучше хоть какие-то, пусть даже заниженные оценки, чем никаких.

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

17458907.195e50a0db7e7428ccd693c67f635406.1186223110.9626a2d31cf793845f340f27c23ea8b8

К вопросу о "стандартах кодирования"

2007-08-03T09:14:00.000+04:00

На форуме Artima Developer Spotlight появилась тема: "What's the Most Effective Code Style Policy?", посвящённая обсуждения "стандартов кодирования".

Немного о терминологии

На самом деле даже сам термин "coding policy" или "стандарты кодирования" многозначен. Разные авторы или компании вкладывают в него разные смыслы, в зависимости от которых область применения стандартов может быть существенно сужена или наоборот расширена.

Рассмотрим возможные смыслы термина:

Стиль и синтаксис форматирования исходного кода программы

Расстановка скобок
Использование пробелов и пустых строк
Правила написания выражений (for, if, while и так далее)
Правила именования переменных
Правила объявления переменных
Правила написания комментариев
Правила использование отступов

Иногда к содержанию первого пункта могут быть добавлены элементы "управления конфигурацией"

правила именования файлов
структура файлов проекта
правила использования системы контроля версий
стандартизация используемых средств разработки

Иногда к стандартам кодирования могут также быть добавлены "best practices" того, как надо писать программы, в зависимости от определённого языка программирования, среды разработки, компании или специфики разрабатываемого продукта (типичным примером может служить требование "всегда создавать в классе виртуальный деструктор", для C++)

Конечно же, "стандарты кодирования" могут включать в себя содержимое и всех пунктов сразу, и какую-то их смесь, а также что-то что здесь не упомянуто.

Мой взгляд

Здесь я хочу ответить на вопрос, заданный в теме на форму Artima - "What's the Most Effective Code Style Policy?".

Обращаю внимание, что все дальнейшие рассуждения касаются "стандартов кодирования" в смысле (1) и оставляют аспекты (2) и (3) без внимания.

Основной необходимостью существования "стандартов кодирования" обычно называют (некоторые части процитированы по Code Conventions for Java Programming Language, они отмечены '*'):

Необходимость работ над одним и тем же исходным файлом нескольким программистам
Улучшение "понятности" исходного кода, что позволяет программистам более полно и быстро понять новый для них код (*)
Необходимость сопровождения (исправления ошибок, внесения небольших исправлений) кода и тот факт что в большинстве случаев споровождение осуществляется не тем же человеком, который является исходным автором кода. (*)
Программист, работающий над исходным кодом, который написан не в "любимом" или "привычном" стиле будет тратить на его исправление больше времени (аргумент Bill Venners из исходного сообщения в форуме).

Моё мнение состоит в том, что усилия на создание и поддержание "стандартов кодирования" в большинстве случаев существенно выше чем затраты на "понимание" или поддержку кода, написанного "в другом стиле". Я конечно не имею ввиду примеры из "Obfuscated C Code Contest" :-) В большинстве случаев, код написанный вменяемым программистом понятен другому вменяемому программисту, вне зависимости от того, как именно расставлены в нем фигурные скобки или именованы переменные. Единственной неприятностью могут быть различия в настройках отступов и табуляций/пробелов, при просмотре кода различными текстовыми редакторами, просмотрщиками и программами сравнения.

Поэтому в моей голове всегда существовал такой "стандарт кодирования":

Единообразная настройка длины табуляции (tab length)
Использование пробелов вместо табуляций
При правке кода пользоваться тем стилем, который используется в этом коде

Вот собственно и все. А если Вы или Ваш коллега пишете код в стиле "Obfuscated C Code Contest", то подумайте может проблема должна быть решена не при помощи "стандартов кодирования", а как-нибудь по-другому?

17458907.195e50a0db7e7428ccd693c67f635406.1186161181.ba176d26a55281a16d8fd8b02a541ce8
17458907.48319b4763d4aa2700c0fda3363b9fab.1186391267.b8da257c7d1fa1c830df3b9f73d6fb72

"Вера" в науку

2007-07-31T09:22:00.000+04:00

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

Именно этот вопрос и хочется обсудить. Является ли наука своего рода «верой»? Я осознаю, что затрагиваю в этом небольшом обсуждении такие вопросы, которыми занимались и продолжают заниматься великие мыслители и ни в коей мере не пытаюсь себя к ним причислить, но тем не менее мне кажется что многие их мысли так и не нашли своего читателя, во многом из-за не совсем внятного, перегруженного деталями изложения.

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

Введение

Нет никаких сомнений в том, что философия, наука и религия, в их современном виде произошли от общего «корня». Когда-то все они представляли собой некий сплав, насыщенный идеями, из которого впоследствии выросли имеющиеся различные направления.

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

О научном мировоззрении

(заголовок взят из заголовка статьи В.И Вернадского «О научном мировоззрении», опубликованной в журнале «Вопросы философии и психологии», 1902)

Научные и религиозные мыслители отличаются друг от друга прежде всего мировоззрением. Именно поэтому сравнение или практически любые споры на темы «Есть бог или нет» между двумя достаточно разумными и эрудированными собеседниками никогда не могут закончится победой одного из них. У них просто разный взгляд на мир, разная картина мира, и у каждого из них она непротиворечива. Именно поэтому спор не может привести к чьей-либо победе, они оба правы. Поэтому же являются достаточно бессмысленными споры представителей религиозных конфессий или философских течений между собой – при условии непротиворечивости их построений (или неспособности спорщиков выявить противоречия), каждый останется при своём мнении и будет прав.

Для понимания отличий между наукой и религией необходимо представлять себе картину мира учёных, научное мировоззрение.

Как мне кажется (как я уже говорил, я не учёный и поэтому все здесь изложенное конечно же является спекуляцией), научное мировоззрение основано на нескольких «столпах»:

Здоровый консерватизм
Стремление к поискам истины, к открытию нового, к познанию окружающего мира
Необходимость достоверности наблюдений
Научный подход
Непрерывность поиска истины

Здоровый консерватизм заставляет ученого тщательно проверять и перепроверять полученные результаты, стараться всегда увязать новые результаты с уже имеющимися фактами, найти не вкралась ли в рассуждения и вычисления ошибка.

Стремление к поискам истины, представляет из себя обратную сторону консерватизма. Это собственно и есть мерило «здоровья» консерватизма. Каждое подтверждённое расхождение с господствующими в настоящий момент представлениями – это вызов учёным, «звоночек», прислушавшись к которому, необходимо расширять существующие теории или даже полностью отметать их и создавать новые. Абсолютных истин нет, каждый раз наука создаёт модели, все более приближающиеся к реальности, на основе того набора фактических данных, которыми она к данному времени располагает.

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

Научный подход представляет из себя способ исследования и получения новых знаний и обычно выглядит так:

Наблюдение проблемы
Предложение возможного объяснения проблемы – гипотезы
Предсказание возможных последствий, в том случае если гипотеза верна
Проверка предсказания

Необходимо также понимать разницу между гипотезами и теориями и «господствующими в настоящий момент в науке представлениями». Наличие огромного набора экспериментальных фактов вынуждает добросовестных учёных, создающих новые теории и гипотезы проверять практически все их. Это необходимо, либо для выяснения ложности фактов, либо для отбрасывания теории или гипотезы, как противоречащей наблюдениям. В каждый конкрентный момент в науке существует свод «господствующих представлений». Они не обязательно являются истинными. Помните, что наука – это набор последовательных моделей, которые должны приближаться к истине все больше и больше. Однако проверить то, приближается модель к истине или нет можно только лишь экспериментом. В разные времена господствовали разные научные представления, которые заменялись новыми с появлением новых экспериментальных фактов. И с каждым годом фактов становится все больше и больше! Поэтому старые, устаревшие или применимые только в частных случаях теории отбрасываются (или устанавливаются границы из применения, как с механикой Ньютона) и заменяются новыми, включающими их в себя, как частные случаи. В этом и состоит непрерывность поиска истины.Мы не можем быть уверены в том, что господствующие в данный момент научные преставления истинны и навсегда останутся таковыми. Мы можем лишь быть уверены в том, что они согласуются с теми набором достоверных экспериментальных фактов, которые накопило человечество (без сомнения может быть так что не все имеющиеся факты достоверны или в теориях есть ошибки).

Коренное отличие науки от религии и философии

Теперь, когда разобран вопрос о том, что представляет из себя научное мировоззрение можно ответить на основной вопрос статьи – является ли наука предметом веры?

Данный вопрос был затронут известным учёным, В.И. Вернадским в его работе "Научная мысль, как планетное явление" (написана в конце 1930-х годов).

В.И. Вернадский пишет:

"Есть одно коренное явление, которое определяет научную мысль и отличает научные результаты и научные заключения ясно и просто от утверждений философии и религии - это общеобязательность и бесспорность правильно сделанных научных выводов, научных утверждений, понятий, заключений. Научные, логически правильно сделанные действия имеют такую силу только потому, что [...] в ней [в науке] существует область фактов и обобщений, научных, эмпирически установленных фактов и эмпирически полученных обобщений, которые по своей сути не могут быть реально оспариваемы. Такие факты и обобщения, если и создаются временами философией, религией, жизненным опытом [...] не могут быть ими как таковые доказаны. [...] Общеобязательные научные истины не являются самоочевидными и должны во всех случаях непрерывно проверяться сравнением и реальностью. Эта реальная проверка составляет основную ежедневную работу учёного.
[...]
Как религий, так и философий, поэтических и художественных выражений, здравых смыслов, традиций, этических норм очень много, может быть [...] столько же, сколько отдельных личностей. Но наука одна и едина, ибо [...] они все связаны в единое научное построение и не могут логически противоречить одна другой."

Конечно, современная наука пропитана религиозными, политическими и философскими идеями, однако, как считал В.И. Вернадский «[…] есть часть науки общеобязательная и научно-истинная. Этим она резко отличается от всякого другого знания и духовного проявления человечества – не зависит ни от эпохи, ни от общественного и государственного строя, ни от народности и языка, ни от индивидуальных различий.

Это:

Математические науки во всем их объёме
Логические науки почти всецело
Научные факты в их системе, классификации и сделанные из них эмпирические обобщения»

Хотелось бы отметить, что объяснение основных положений науки, научного мировоззрения, научного подхода требует на мой взгляд специального разъяснения, которое я в меру сил попытался дать в этой статье. Без такого разъяснения наука остаётся для далёких от неё людей слепой системой верований, которой она ни в коем случае не является.

17458907.195e50a0db7e7428ccd693c67f635406.1186148117.6d2ce9534a9cad439ee9664a6e39399e

В защиту науки (несколько книг)

2007-07-28T19:45:00.000+04:00

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

Так вот, современные научно-популярные книги, которые читать не менее интересно чем труды, например, Носовского и Фоменко, существуют (тиражи, правда сказать, невелики, 2500 - 3000 экземпляров).

Вот те из них, что мне удалось прочитать:

Названия говорят сами за себя, но если вы любите читать рецензии, то на две последние книги (вернее мини-книги) есть отличная рецензия, из которой я собственно о них и узнал.

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

Аэропорт

2007-07-14T12:40:00.000+04:00

Я на прошлой неделе дважды посетил аэропорт "Домодедово" ... Много думал.

На веб-странице посвящённой аэропорту сказано:

"Новый реконструированный аэровокзальный комплекс Домодедово – современный пассажирский терминал по обслуживанию пассажиров, предлагающий клиентам услуги европейского класса."

Вот план аэропорта:

Можно на него посмотреть и со спутника вот тут (только хочу обратить внимание на то, что спутниковое фото на момент написания поста старое - сейчас здание стало ещё длиннее).

На плане можно видеть, что аэропорт представляет собой вытянутое в длину
здание. Автостоянка находится слева от здания. Такое расположение удивительно неудобно!!! Порой для того чтобы дойти до нужного места аэропорта нужно идти наверное с километр!!!

И так уж совпало что недавно я перечитывал роман А. Хейли "Аэропорт". Вот небольшая цитата оттуда (с некоторыми сокращениями):

"Как вы считаете, мистер Бейкерсфелд, это верно, что через три‑четыре года в авиации будет сплошной хаос?

— Хаос — вещь относительная, — сказал Мел ... В жизни, мы сталкиваемся с ним в самых разных проявлениях и так или иначе приспосабливаемся.

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

Но репортёр не унимался.

— Что же мы должны предпринять в отношении аэропортов? Что мы можем предпринять?

— Прежде всего мы должны научиться мыслить шире, давать волю воображению. Нужно освободиться от железнодорожного способа мышления.

— Вы считаете, что мы от него еще не освободились?

Мел кивнул.

— К несчастью, мы сталкиваемся с ним довольно часто. Все наши старые аэропорты представляют собой просто имитацию железнодорожных вокзалов, потому что их строителям приходилось опираться на опыт своих предшественников. Потом это стало уже шаблоном. Вот почему и в наши дни так много «вытянутых» аэропортов, где здание аэровокзала тянется до бесконечности и пассажиры вынуждены вышагивать не одну милю.

— А их не перестраивают? — спросил Томлинсон.

— Только кое‑где, и то очень медленно. — Несмотря на серьезность момента, разговор этот задел Мела за живое. — Кое‑где строятся циркообразные аэропорты — вроде пирога с начинкой, с автомобильными стоянками, расположенными внутри самого аэровокзала, а не за его стенами; там пешее передвижение пассажиров по аэровокзалу сокращено до минимума с помощью скоростных горизонтальных эскалаторов, а кроме того, самолеты подъезжают к пассажирам, а не наоборот. Это говорит о том, что аэропорт начинает завоевывать себе место как самостоятельная единица, а не просто приставка к чему‑то."

А. Хейли написал роман "Аэропорт" в 1968 году.

Для сравнения интересно посмотреть спутниковые фотографии скажем Шереметьево 2 или аэропорта JFK в Нью-Йорке. Они устроены точно так, как описано в романе почти сорокалетней давности (JFK - состоит из нескольких терминалов, каждый из которых похож на Шереметьево 2). А вот "современный пассажирский терминал по обслуживанию пассажиров, предлагающий клиентам услуги европейского класса" как то не очень. Более того как я вижу его ещё и расширяют. В стороны.

Я конечно понимаю, Домодедово старый аэропорт и строился в те времена, когда вытянутая форма была предпочтительной. НО, стоянка тогда была не сбоку от аэропорта, а ПЕРЕД ним (что кстати видно на старой спутниковой фотографии, ссылку на которую я привел - на ней ещё есть ДВЕ стоянки - ПЕРЕД зданием и сбоку; сейчас стоянки перед зданием не осталось). И кроме того тогда аэропорт был существенно короче чем сейчас.

Интересно, почему при масштабной перестройке которая сейчас происходит ничего из вышесказанного не учитывается?

А может я неправ и на самом деле все здорово и я просто не в теме?

О совещаниях ...

2007-07-07T16:35:00.000+04:00

Почему-то последнее время вокруг меня часто всплывает тема о совещаниях. И люди говорят, и на RSDN тема появилась.

Я очень уверен в том, что почти всегда совещания на самом деле не нужны. Ну, то есть, в подавляющем большинстве случаев все полезное, что делается во время совещания, можно сделать и так, в рабочем, что называется, порядке.

Про то, как правильно проводить совещания, многократно расписано и рассказано (необходимость повестки дня, ознакомительных материалов, присутствие только тех, кто действительно нужен, наличие ведущего и так далее). Другое дело, нужны ли они вообще.

Ну то есть, конечно поймите меня правильно, совещания нужны. Но не всякие и не всегда.

В моей голове есть три типа совещаний.

Совещания, которые необходимо провести, поскольку что-то произошло.

Скажем выяснилось, что по какой-то причине код в проекте раздублирован, то есть нарушен принцип DRY. В этом случае необходимо конечно устроить небольшое совещание с участием тех, кто этот принцип нарушил и договориться о том, как решить проблему
Совещания, которые необходимы для определения 'общего направления', создания 'единого видения', 'одинакового понимания' и тому подобного
"Регулярные" совещания. Еженедельные "status meetings" и так далее

Важность и необходимость этих совещаний распределена на мой взгляд в порядке перечисления. То есть, самыми важными и действительно необходимыми являются совещания типа (1), менее нужны совещания типа (2) и самыми ненужными являются совещания типа (3).

Удивительным фактом при этом является то, что количество совещаний (по моему опыту) распределяется совершенно противоположным образом. То есть регулярные совещание проводятся очень часто (регулярно :-) ), совещания второго типа ("объединяющие") время от времени, а вот совещания первого типа (срочные) частенько "задвигаются" и объединяются с совещаниями типов (2) и (3).

И это ужасно! Ведь на самом деле совещания типа (1) - это и есть моменты, когда совещания действительно нужны. Что-то произошло, а следовательно необходимо срочно предпринять меры. Они происходят в тот самый момент, когда обнаружилась проблема и когда свежи в головах её причины, а значит легче всего найти решение.

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

Что же до третьего типа ... Мне кажется, что совещания типа (3) - considered harmful :-).
По нескольким причинам:

Если вопросы, которые поднимаются на этих совещаниях, не были ранее подняты на совещаниях двух других типов, то значит они были отложены, ими просто не захотели заниматься, а чего в этом хорошего?
Реальный статус проекта начальник может узнать непосредственно у подчинённого ("в рабочем порядке"), для этого нет необходимости созывать всех и заставлять каждого слушать ответы остальных и ждать своей очереди. (Хочу обратить внимание, что если у начальника слишком много подчинённых, то это само по себе является проблемой. Оптимальное количество подчинённых, по всей видимости, является равным оптимальному количеству сущностей, которыми может одновременно оперировать человек, то есть 7+-2 G. Miller. Magical Number Seven)
Если начальник узнает состояние дел у своих подчинённых раз в неделю, а остальное время находится в неведении ... то он плохой начальник
Очень часто подобные совещания носят ритуальный характер (то есть совещания в которых важна сама форма поклонения боссу). Если подобные совещания нужны начальнику для поддержания собственной значимости, то не совсем понятно стоит ли это того, чтобы тратить столько времени подчинённых (взято из Tom DeMarco, Timothy Lister Peopleware: Productive Projects and Teams)
Если ритуальные совещания нужны для поддержания в подчинённых "желания работать", то не значит ли это что какие-то другие притягивающие силы в организации отсутствуют (например, зарплата недостаточно хороша ;-) )?

Поэтому, когда Вам, как начальнику, хочется провести совещание третьего типа ("Отныне каждый вторник в 10 утра мы будем обсуждать статус проекта!") задумайтесь - "Может, что-то в консерватории подправить?"

Карты мира :-)

2007-07-03T13:39:00.000+04:00

Довольно давно мне попалась где-то в Сети довольно смешная карта "World according to America". Вот сделал небольшую подборку из такого рода карт :-)

Первый в мире язык программирования

2007-06-24T17:53:00.000+04:00

Мне всегда казалось, что первым был Фортран, что, в частности отображено и в наверное наиболее известной диаграмме истории языков программирования. На самом деле по влиянию и известности Фортран конечно и был первым. Однако с исторической точки зрения - нет.

[Если быть совсем точным, то уж по настоящему первым языком программирования была, по всей видимости, та нотация, с помощью которой были написаны программы Чарльза Бэббиджа в знаменитой статье Ады Августы Байрон, графини Лавлейс "Sketch Of the Analytical Engine"(статья представляла собой перевод статьи итальянца Менабреа о работе разностной машины Бэббиджа и, содержала существенное дополнение, написанное самой Адой Августой). Однако это был не вполне язык программирования, да и машина, для которой он предназначался существовала только в уме гениального человека. Замечу кстати, что в 1991 году музей науки в Лондоне создал по чертежам Бэббиджа его машину и она сейчас существует в рабочем состоянии]

Итак, первый язык программирования. Это был вовсе не Фортран, а язык с удивительным названием - Plankalkül, то есть в переводе с немецкого "Исчисление планов" или "План вычислений", был разработан немецким учёным, изобретателем и конструктором Конрадом Цузе в нацистской Германии между 1942 и 1945 годами.

[Цузе также сконструировал несколько различных моделей компьютеров. Например его Z3 тоже был создан раньше знаменитых Marc I и ENIAC и являлся при этом вполне полноценной машиной. ]

Утверждается, что всех своих достижений Цузе добился абсолютно самостоятельно, не обладая сведениями ни о работах американцев и англичан, проводившихся в близкое время, и даже не зная о работах Бэббиджа.

Создание языка программирования было естественным продолжением работ по созданию "железной" части компьютеров. Сам Цузе пытался с его помощью писать программу для игры в шахматы. Работы над языком были закончены около 1946 года, однако развития язык не получил и даже написанное руководство увидело свет только в 1972 году. Из-за этого язык оказался неизвестным и существенного влияния на дальнейшее развитие индустрии не оказал (в сравнении например с тем же Фортраном).

Тем не менее Plankalkül несомненно был первым в мире языком программирования высокого уровня. Основные концепции языка включают:

Наличие подпрограмм (и это в 1940-х годах!!!)
Наличие операции присваивания (=>)
Циклы
Условный оператор (if)
Возможность манипуляций с массивами
Возможность манипуляций со списками

При создании языка Цузе собрал множество проблем, которые были поставлены инженерами и учёными. Для демонстрации того, что язык действительно способен решать эти проблемы было написано огромное количество примеров программ (в частности около 60 страниц примеров для программы играющей в шахматы).

Одной из проблем языка был чрезвычайно сложный и очень непривычный современному программисту синтаксис. Вот пример присваивания A[5] = A[4]+1 на языке Plankalkül:

Здесь V - это строка для индексов, S - строка для задания типов данных, 1.n - обозначает целое число размером n бит.

В настоящее время институт Цузе в Берлине создал компилятор языка Plankalkul. На сайте института также представлены тексты работ Конрада Цузе и симуляторы созданных им компьютеров.

Plankalkül не оказал существенного влияния на другие языки. Но тем не менее историческое первенство - за ним.

Комментирование и системы контроля версий

2007-06-14T19:05:00.000+04:00

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

Ситуация эта выглядит примерно так. Программисту хочется внести какое-то изменение в код, и он поступает следующим образом: комментирует старый кусок, а затем вставляет на его место исправленный. Таким образом в исходном файле остаются ОБА куска кода одновременно.

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

Данный вид комментирования представляет собой подмену (причём недостаточно функциональную) системы контроля версий.
Данный вид комментирования неудобен для тех, кто будет разбираться в коде после вас.

Подмена системы контроля версий

В чем состоит подмена? В том, что система контроля версий как раз и предназначена для того, чтобы дать возможность увидеть кто, когда, зачем и каким именно способом изменил данный кусок кода. Комментирование только дублирует информацию уже имеющуюся в системе контроля версий, причём не всю её (подобные комментарии обычно ведь не стандартизированы - что захочет там разработчик написать, то и напишет). Таким образом подобные комментарии являются избыточными.

Неудобство для "будущих поколений"

Подобные комментарии, помимо того что являются избыточными (с чем довольно легко можно смириться), могут также являться источником дополнительных сложностей для программистов, которые не являются авторами первоначального кода.

Дело в том, что подобные закомментированные и давно неиспользуемые куски:

При исследовании кода методом поиска :-) могут вполне попасться в результаты, а значит придётся затратить дополнительное время на их изучение
При интенсивном использовании сильно замусоривают код, что также создаёт дополнительные сложности
Комментарии многими воспринимаются как пояснение относительно работы данного куска кода (и правильно воспринимаются, именно для этого комментарии и нужны). Поэтому закомментированная часть кода, если комментарий был использован вместо системы контроля версий, может вызвать у читающего затруднения с пониманием - зачем здесь комментарий? может быть кто-то что-то тестировал и забыл убрать комментарий? Короче говоря, возникает лишний повод задуматься.

Мой общий вывод из вышеизложенного такой (нагло подделываясь под классика):
"Commenting code out considered harmful". Неиспользуемый код нужно удалять, а не комментировать. Конечно, всегда бывают "ситуации" и мы здесь говорим о каком-то общем, "среднем" случае.

P.S. Да, современные интегрированные среды разработки позволяют достаточно легко бороться с перечисленными выше недостатками (outlining; поиск с использованием регулярных выражений; интеллектуальный поиск, понимающий что комментарии нужно пропускать). Но они же часто содержат функции, позволяющие вообще не заниматься подобным комментированием, например IntelliJ Idea содержит замечательную функцию Local History, являющуюся по сути постоянно включённой системой контроля версий.

А самое главное - зачем создавать проблемы, чтобы потом их решать, у нас ведь и так есть чем заняться?

Тони Хоар: советы выпускникам

2007-06-11T20:28:00.000+04:00

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

Само выступление небольшое, около 17 минут, по ссылке которую я привёл есть и транскрипт, что может быть полезно тем кому не понравится замечательный английский акцент сэра Тони.

Самым занимательным моментом мне показалось сравнение принципов "работы на науку" и "работы на корпорации". Если при работе на науку необходимо создавать что-то новое, то то при работе на корпорацию, наоборот почти всегда необходимо найти возможность воспользоваться чем-то уже существующим. Об этом различии стоило бы помнить многим программистам :-)

P.S. Тони Хоар сейчас работает где бы вы думали ... ну конечно в Microsoft Research.

Skype vs. IIS 5.1

2007-06-06T17:37:00.000+04:00

Сегодня возникла необходимость установить на домашней Windows XP машине IIS. Установил, открыл snap-in Internet Information Services, и увидел что 'Default Web Site' не запущен. Нажал 'Start item'. И тут же увидел потрясающее сообщение об ошибке:

Unexpected error 0x8ffe2740 occurred.

Поиск известно где показал мне следующую статья в MS knowledge base:
http://support.microsoft.com/kb/816944

Статья эта говорит нам о том что подобное сообщение возникает в случае, если существует конфликт по TCP портам - какая-то программа уже использует порт, прописанный в Default Web Site. Там по умолчанию прописан конечно порт 80.

Ну дальше все уже наверное очевидно из названия поста. В лучших традициях Mark Russinovitch я запустил его замечательную утилиту Process Explorer и после недолгого изучения обнаружил:

То есть как видно Skype использует 80 порт. В настройках Skype видно следующее:

Это-то как раз и есть причина проблемы. Следовательно для того чтобы избежать описанной проблемы нужно либо выключить соответствующую галочку в Skype (и перезагрузить его), либо поменять порт по умолчанию в IIS Default Web Site.

P.S. На моей машине также (в тестовых целях) установлен пакет Денвер, представляющий из себя "набор дистрибутивов и программная оболочка, используемые Web-разработчиками (программистами и дизайнерами) для отладки сайтов на «домашней» (локальной) Windows-машине без необходимости выхода в Интернет". Денвер это, в частности, Apache - так вот ему наличие Skype не мешает, все нормально работает ... Вот соответствующая картинка:

Возможно работает все до тех пор пока кто-то не "позвонит" в Skype на 80 порт?

Принцип DRY

2007-06-05T13:14:00.000+04:00

Про принцип DRY все знают. Ну даже если кто-то и не знает самого сокращения, то уж смысл известен наверняка. Напомню, DRY расшифровывается как Don't Repeat Youself. То есть "Не повторяй самого себя". Первый раз с самим сокращением я столкнулся в книге The Pragmatic Programmer: From Journeyman to Master. На самом деле принцип все мы знаем очень давно, даже если не осознавали его как "принцип" или что-то глубоко умное и философское (в Википедии принцип относится к категории Software Development Philosophies).

Вроде бы нет ничего проще (цитирую по русскому переводу вышеупомянутой книги): "Каждый фрагмент знания должен иметь единственное, однозначное, надёжное представление в системе".

Ну то есть пиши функцию (или класс) и пользуйся ею, а не пытайся сделать в разных местах одно и тоже заново.

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

Тем не менее, во многих случаях следование этому принципу сильно может облегчить жизнь программистам работающим над проектом. Сузим немного область применения принципа (авторы указывают что его можно применять буквально ко ВСЕМ составляющим ПО - не только исходному коду, но и документации, системам сборки, требованиям и так далее).

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

Откуда берутся такие ошибки? Кто в них виноват?

Программисту, которому необходимо добавить новое поле в диалог плюётся "Вот "@#$%^&*! Ну кто так пишет! И диалога два, и поведение в них чуть-чуть разное и по разным принципам они написаны, и сопутствующие классы разные!" После этого он открывает историю в системе контроля версий, смотрит фамилию предшественника и ... Ну сами понимаете. Тут уж предшественнику вполне может достаться по первое число. Зачем скопировал? Почему все то же самое, но чуть-чуть по-другому?

И что потом делает наш гипотетический программист? Вставляет исправления в ОБА места. Почему в оба? Почему он не слил два диалога в один? Ну понятно почему. Потому что у него сроки, потому что у него следующая работа, потому что у него начальство, потому что разбираться где ещё используются эти диалоги нет ни времени ни желания ...

А потом наступает момент когда кому-то нужно добавить в диалог ещё одно поле.

Виноват ли наш гипотетический программист? Или может быть виноват "самый первый" программист - тот кто из одного диалога сделал два? Зачем он так сделал?

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

Все это - повторюсь ещё раз - не ошибки программиста. Все это - ошибки руководства. В большинстве случаев непосредственного, то есть людей которых я в своём посте про должности и их названия называл team leader. Кстати, небольшое замечание - когда я пишу про программистов и team leader-ов я имею ввиду роли. В работе над меленьким проектом один и тот же человек может исполнять все роли - и тогда проблема дублирования для него как программиста будет ошибкой его самого, но в роли собственного руководителя.

Задача руководства как раз и состоит в том (не только в этом конечно), чтобы организовывать "переход" на новые технологии, архитектуры, отслеживать, чтобы все это доводилось до конца и чтобы на это хватало времени. А также для оценки необходимости самого этого перехода.

Поэтому в следующий раз, если увидите две разных реализации одного и того же не торопитесь ругать программиста.

Интересный блог

2007-05-31T12:17:00.000+04:00

Я уже достаточно давно читаю блог Элдара Мусаева "Мысли которые не удалось удержать в голове". Читать собственно начал с того момента как прослушал его замечательный ролик на русском Channel 9 - "Про маразм и program management", зашел на блог ... да так там и остался :-) Рекомендую!

Две интересных статьи

2007-05-24T16:26:00.000+04:00

Обнаружил две интересные статьи. В частности они касаются некоторых вопросов, которые обсуждались в моих постах про "Дао Русского программиста", про то как научиться программировать и про то какие знания необходимы программисту.

Почитайте, интересно:

Полезный ключ компилятора MS VC++

2007-05-22T14:12:00.000+04:00

Я уже довольно давно читаю блог команды разработчиков Visual C++ и должен сказать что это довольно таки занудный блог. Но вот последняя статья в нем - буквально таки жемчужина.

Не очень часто мы сталкиваемся с проблемой неодинакового выравнивания одних и тех же классов в разных единицах трансляции. Проблему трудно диагностировать и даже очень трудно. Так вот статья рассказывает про замечательный и конечно же НЕ документированный и не поддерживаемый ключ компилятора:

/d1reportSingleClassLayoutXXX, где XXX - интересующее нас имя класса.

При компиляции с этим ключом, компилятор показывает, как с его точки зрения "разложился" класс XXX. Вот код из статьи:

// a.h – share class definition (code has been corrected from original post)

#pragma once

class Test_A {
public:

Test_A(){ c = 'X'; data = 0; }

~Test_A(){ if(data) delete [] data; }

char c;
char* data;

};

void Test_A_Loader(Test_A&);

// loader.cpp - loader defn.
#include //for strcpy
#include "a.h"

void Test_A_Loader(Test_A& a) {

a.c = 'p';
a.data = new char[10];
strcpy(a.data, "3.14159");

}

// main.cpp - main program
#include // for printf

#include "a.h"

int main(){

Test_A a;
Test_A_Loader(a);
printf("%c : %c %c %c %c\n", a.c, a.data[0], a.data[1], a.data[2], a.data[3]);

}

Данный код компилируется вот так (для того чтобы воспроизвести ошибку):

cl main.cpp /Zp2 /c
cl loader.cpp /Zp1 /c
link main.obj loader.obj

При этом конечно возникает ошибка с выравниванием, поскольку класс Test_A выровнен по разному в единице трансляции main.cpp и в единице трансляции loader.cpp.

А вот вывод компилятор при использовании волшебного ключика '/d1reportSingleClassLayoutTest_A' (почему то в статье вывод компилятора целиком не приведён, а мне кажется что это интересно):


1>------ Build started: Project: ClassLayout, Configuration: Debug Win32 ------
1>Compiling...
1>stdafx.cpp
1>Compiling...
1>loader.cpp
1>class Test_A size(5):
1> +---
1> 0 | c
1> 1 | data
1> +---
1>class Test_A size(5):
1> +---
1> 0 | c
1> 1 | data
1> +---
1>Compiling...
1>ClassLayout.cpp
1>class Test_A size(6):
1> +---
1> 0 | c
1>   | <alignment member> (size=1)
1> 2 | data
1> +---
1>class Test_A size(6):
1> +---
1> 0 | c
1>   | <alignment member> (size=1)
1> 2 | data
1> +---
1>Linking...
1>Embedding manifest...
1>Build log was saved at "file://l:\ClassLayout\Debug\BuildLog.htm"
1>ClassLayout - 0 error(s), 0 warning(s)
========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ==========

Вот такой вот замечательный ключик. А я уж от их блога отписываться хотел.

Ответ на статью: Путь без конца или Дао русского программиста

2007-05-16T13:19:00.000+04:00

Я сегодня выступаю в не очень привычном для себя жанре. Этот пост - ответ.

Я думаю что Максима Кононенко, также известного как Mr.Parker знают все. Ну если и не знают, то слышали про него уж точно очень многие. Он - создатель популярного сайта Владимир Владимирович™, известный блоггер, сетевой писатель и журналист. А также программист. Вот я как раз про это. Некоторое время назад вышел пост Максима под названием: Путь без конца или Дао русского программиста. Именно этот пост я и хочу здесь разобрать. Так что уж не обессудьте, для того чтобы читать дальше придётся сначала сначала прочитать исходный пост.

(замечание: данный ответ также опубликован и как комментарий к самому посту Максима - только без вступительной части)

К вопросу о терминологии

Похоже, что в исходном посте термин "программирование" понимается совсем не так как понимаю его например я. В моей голове есть несколько терминов, несколько "ролей", нужных например для того чтобы организовать компанию, которая производит и продаёт программы. Вот этот (скорее всего неполный) список:

Руководство разных уровней
Бухгалтер
Программист
Тестировщик
Системный администратор
Менеджер проекта - подробнее об этой роли я писал вот в этой статье
Менеджер продукта - об этой роли я также писал вот в этой статье
Специалист по продажам
Специалист по рекламе
Специалист по связям с общественностью
Секретарь
Специалист технической поддержки
....

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

Поэтому, на мой взгляд, не очень важно что программисты не умеют продавать программы - это не их задача.

О предмете программирования

Я хочу остановиться на вопросе о предмете программирования. И я прочёл (не буквально, а "увидел", "интерпретировал") в самом посте, а также, кажется в каких-то ответах автора к комментариям на LiveJournal (затрудняюсь их сейчас здесь привести) мнение о том, что программирования как предмета не существует. То есть мне показалось, что автор утверждает: нет никакой "computer science", есть несколько областей математики, плюс некоторые ремесленные приёмы.

Я увидел эту мысль и в утверждениях что "нигде программированию не учат 5 лет" и в том что "что программирование - не ахти какое сложное занятие".

Я же убежден что "программирование имеет свой предмет, не сводящийся ни к конкретным языкам и системам, ни к методам построения быстрых алгоритмов" (Шень А. "Программирование: теоремы и задачи"). Попробую объясниться.

Дело в том, что программирование, также как и математика, например или к примеру, упоминаемая автором медицина - это очень "широкая" дисциплина. Человек, пишущий скажем компилятор - программист, человек пишущий "графический движок" игры - тоже программист, пишущий plug-in к браузеру Firefox - тоже, пишущий адресную книгу для сотового телефона тоже, но и пишущий на php формочку, чтобы отправить письмо со своего веб-сайта - тоже. Есть масса разных ответвлений и уровней. Как и везде - есть сложные части, а есть простые, есть требующие больших знаний в "сопутствующих" областях, а есть меньших.

Тем не менее, есть некоторые общие моменты, которые сводят всех этих людей. Это необходимость сформулировать и выбрать абстракции, организовать взаимодействия объектов, построенных на основе этих абстракций между собой, продумать последовательность этих взаимодействий и добиться желаемого результата. (для буквоедов: не придирайтесь к слову "объекты" - я не имел ввиду объектно-ориентированную парадигму проектирования). Это очень важно иметь ввиду при рассмотрении дисциплины программирования.

Остальное

Все основные тезисы мне не кажутся важными, чтобы с ними спорить. В них есть доля истины, но в основном, как мне кажется они составляют некоторый пересказ известной шутки, которую можно найти например тут и относиться к ним я бы стал также как к этой шутке - с юмором.

P.S. Вот ещё что хотелось сказать. Ведь Максим Кононенко написал ещё и рассказ Покемон. Удивительно что один и тот же человек написал две такие совершенно разные [по духу] работы.

Научиться программировать ...

2007-05-10T12:30:00.000+04:00

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

Это сложный вопрос и я конечно не смогу на него ответить, так что я разочарую тех, кто надеялся получить какой-то готовый рецепт. Когда-то давно я прочитал замечательное эссе Питера Норвига на эту тему. Эссе называется "Научитесь программировать за 10 лет". Его можно прочитать в первоисточнике, а также в русском переводе. Эссе посвящено тому, как по мнению Норвига нужно подходить к (само)обучению программированию, а название это естественно пародия на многочисленные книги типа "Научитесь XXX за 21 день".

Сегодня я ещё раз перечитал это эссе, и заметил там для себя что-то, чего не замечал раньше. Ну, точнее замечал, но как-то не придавал должного внимания. А именно, отношение Норвига к поверхностному обучению. В самом начале эссе, он в шутку разбирает что бы могло на самом деле обозначать название книги "Изучите Паскаль за 3 дня". В частности, Норвиг пишет: "... за три дня вы можете получить только поверхностное представление о языке, а не глубокое понимание. Как говорил Александр Поуп - "Недостаточное обучение - это очень опасная вещь".

Это очень верное замечание, на которое стоит обратить внимание. Именно поэтому в одном из своих предыдущих постов, посвящённом вопросам на собеседовании, я и писал что необходимо проверять базовые знания. Задавать "простейшие" вопросы(в кавычках, поскольку это вопросы на самом деле не простые, просто мы настолько привыкли давать на них ответы-"отписки", что не очень задумываемся о сути). Проверять именно глубину знаний. Проверять что человек умеет программировать, и не впадёт в ступор, когда закон
"закон дырявых абстракций" (The law of leaky abstractions") покажет себя.

Перечитайте ещё раз статью Норвига (ну или прочитайте её, если не читали раньше). На самом деле она ведь не только про программирование ;-)

С праздником!

2007-05-09T00:00:00.000+04:00

Поздравляю!

Хорошие вопросы

2007-05-02T11:22:00.000+04:00

Про вопросы на собеседовании очень многие уже писали. Но мне кажется все писали неправильно :-) Вообще-то я глубоко убеждён в том, что собеседование - процесс практически безнадёжный и что единственный способ понять подходит ли человек для работы - это поработать с ним. Ну поскольку этот способ слишком дорогой, то приходится прибегать к собеседованию.

Все соображения на тему "Как проводить собеседование" напоминают мне одну известную шутку.

Молодую девушку пригласили на свидание и она спрашивает маму - "Как вести беседу?" Мам отвечает - "Ну поговорите сначала о погоде, потом, к примеру, о музыке, а потом скажи что-нибудь остренькое". Во время свидания сразу же после встречи девушка и говорит: "Какая чудная погода, училась музыке три года, бритва."

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

Поэтому я просто приведу примеры вопросов, которые могли бы спровоцировать дискуссию, раскрыть насколько хорошо человек понимает основы (не сгруппированы по тематике):

Что такое порт? (в смысле TCP/IP порт) Зачем он нужен? (В смысле - для чего используется)
Зачем нужна операционная система? (В смысле - для чего используется)
Зачем нужны точки в ip-адресе?
Как определить в какую сторону растёт стек?
Зачем нужен компилятор?
Ведь микропроцессор оперирует исключительно двоичными числами? А как же получаются буквы?
Что такое программа? (компьютерная программа)
Что такое "сложность вычисления"?
Зачем нужны системы управления базами данных? Да и сами базы данных?
Что такое ASP (или JSP, или PHP, или ... )? На самом деле этот вопрос не совсем то, чем кажется. Я вероятно просто не смог его аккуратно сформулировать. В качестве ответа я конечно ожидал бы не расшифровку аббревиатуры и даже не краткое описание самой технологии. Я ожидал бы беседы о том, как работает типичный web-сайт.

Замечание: некоторые из вопросов могут показаться слишком лёгкими или слишком "общими" или даже оскорбительными чтобы задавать их человеку с серьёзным опытом работы. Мне кажется, что это не так.

Вопросы являются лёгкими, если ты знаешь правильные ответы. Это прекрасно!
"Общими" или даже "расплывчатыми" вопросы сделаны специально - чтобы спровоцировать обсуждение.
А насчёт того можно ли задавать человеку с 10-летним опытом работы вопрос "что такое программа"... Ну понимаете, представьте себе на секундочку, что он не ответит.
(кстати, в качестве ответа на такой вопрос вполне могут послать в края отдалённые и всем известные ... в большинстве случаев я бы считал это правильным ответом :-))

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

Более того, мне хотелось бы надеяться, что эти вопросы полезны сами по себе. Что я имею ввиду? Многие вопросы для собеседований ценны только до тех пор, пока кто-то не прочитал на них ответ. В частности, такой проблемой страдают многие "каверзные" вопросы, такие как задача о взвешиваниях 8 монет, перевозе разных тварей через реку и так далее. В большинстве случаев, при задавании подобных вопросов проверяется не столько "логическое" мышление, сколько слышал раньше человек этот вопрос (и ответ на него) или нет.

Я же надеюсь, что вопросы, подобные тем которые я здесь привёл, не теряют своей ценности после того как человек узнал на них ответ. Если я не знал ответа на вопрос зачем нужна операционная система, не понимал этого для себя, принимал её существование как данность, не задумываясь о причинах, по которым люди решили создать подобную сущность, то обсуждение всего этого меня обучит. А это и есть самое главное. А уж научиться отвечать на вопрос о том как в С++ при помощи шаблонов (templates) посчитать факториал на этапе компиляции я смогу позже. Да и нужно ли это?

Make Love, Not Warcraft

2007-04-26T21:04:00.000+04:00

Уже довольно давно многие успели посмотреть замечательный мультик "Make Love, Not Warcraft", но с тех пор его стерли с YouTube. Тем не менее он все ещё существует в сети (правда с переводом на русский).

Календарь :-)

2007-04-21T14:35:00.000+04:00

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

Таблица DAY_CATEGORY:

Таблица CALENDAR_DAY_CATEGORY (вернее её начало и конец):

Не комментирую.

Где провести черту: системы контроля версий

2007-04-19T12:15:00.000+04:00

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

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

Про то, что такое система контроля версий и зачем она нужна, я думаю все, кто когда либо программировал, знают. Ну, а если кто не знает, отошлю на википедию.

Несмотря на то, что подобные системы существуют уже очень давно, частенько возникают вопросы по правильному их использованию, а именно - вопросы типа "где провести черту".

Что должно находиться в системе контроля версий?

Ответы на этот вопрос варьируются от "только исходный код" до "всегда используйте систему управления исходными текстами", причём и та и другая стороны вполне категоричны. Где же провести черту? Нужно ли хранить в системе управления исходными текстами все письма, написание которых сопровождало написание программы? А нужно ли хранить там документацию? А различные версии логотипа? А, скажем, внутренние технические документы? А меняющийся, с течением времени, список телефонных номеров разработчиков?

У меня на этот счёт очень простой взгляд. Мы занимаемся производством программного продукта. Производством того, что мы поставляем конечному пользователю (заметим, что конечный пользователь - это "роль" - им вполне можем быть мы сами). Поэтому в системе контроля за исходными текстами должно находиться все что нужно чтобы собрать версию нашего продукта заново. То есть это исходные тексты программы, документация, картинки, сборочные скрипты, тексты лицензионных соглашений и так далее. Очень просто проверить находится ли в системе исходных текстов все что нужно - необходимо взять "чистый" компьютер, поставить на него то программное обеспечение которое необходимо для сборки продукта, "взять" из системы управления версиями какую-то версию продукта и попробовать запустить процесс сборки (сетевой доступ к чему-либо, кроме системы контроля версий можно отменить). Если получится нормальная сборка продукта - значит в системе есть все что должно быть.

Должно ли в системе контроля версий быть что-то ещё? Вопрос вкуса. Мне кажется что на уровне общих "правил" не стоит пытаться засунуть туда все что можно себе представить.

В какой момент вещи должны попадать в систему контроля версий?

Здесь тоже есть масса мнений. Начиная с мнения - "положу перед релизом", до попыток положить каждое изменение, в том числе и неработающий код.

Заметим, что крайности бывают двух видов - "слишком редко" и "слишком часто".

Проблема "слишком редко", на мой взгляд, достаточно легко решается введением практики "ежедневной сборки". Если такая практика существует (даже если сборка не ежедневная, а просто производится достаточно часто), то трудность сама собой исчезнет.

Проблему слишком частого внесения изменений решить несколько сложнее. Часто вводят строгое правило - "не чекинить не работающий код", которое в результате может вылиться у людей в отторжение и даже боязнь внесения кода в систему контроля версий вообще. Данную проблему можно решить разными способами, но на мой взгляд самым простым является заведение в системе контроля версий "своей" ветки для каждого из разработчиков, в которой он сможет работать так, как ему удобно. В момент "сборки" можно просто переложить готовые файлы из личной ветки в общую (ну и сделать "merge" при необходимости).

Замечание для "администраторов"

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

Любая программная система требует регулярного обслуживания, резервного копирования, наличия достаточного места на диске, адекватной производительности компьютера на котором она работает и сети через которую в неё осуществляется доступ. К системам контроля версий это относится в полной мере.

Часто бывает так, что принимается решение не хранить какие-то виды документов или не создавать отдельных каталогов для пользователей из соображений "административного характера". А именно - не хватит места на дисках, резервное копирование будет занимать много времени, не хватит лент, используемая система контроля версий "плохая" и если хранить в ней двоичные документы, то ведёт себя плохо.

Мне кажется, что эти соображения очень опасны. По крайней мере для компании, чьей основной деятельностью и источником заработка является производство программного обеспечения. Представьте себе, что начальник службы безопасности банка скажет - "У нас недостаточно места в главном хранилище, чтобы хранить все ценности, поэтому давайте так - все золото мы оставим в хранилище, а акции и бумажные деньги пусть лежат в кабинетах сотрудников. Здание, в принципе, охраняется, конечно стены и замки в кабинетах не такие надёжные как в хранилище, но ведь и бумажные деньги не столь ценны, как золото". Понимаете, мне кажется что лучше расширить хранилище. Может быть даже купить или построить новое. Для компании, производящей программное обеспечение, нет ничего более ценного чем программисты и исходные тексты написанных ими программ- зачем же на этом экономить?

:-(

2007-04-12T00:00:00.000+04:00

Умер Курт Воннегут. Такие дела(с)

Науку нужно защищать?

2007-04-01T22:47:00.000+04:00

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

Все эти явления получили у нас название "лженауки". Вот определение лженауки, данное академиком РАН Александровым Е. Б.:

Однако, основное содержание термина предполагает лишь заведомую (априорную) ОШИБОЧНОСТЬ позиций оппонентов рациональной науки, отводя в ней обширное пространство для добросовестных заблуждений. Поэтому, в западной литературе обычно используется более мягкий ("политкорректный") термин "псевдонаука", а также "паранаука".

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

Недавно комиссия начала издавать бюллетень "В защиту науки". Бюллетень предназначен для того чтобы:

... развенчивать самые разные направления лже-науки, в том числе и те, которые проникли сегодня в медицину, в образование, в бизнес.

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

Я очень скептически отношусь ко всяким паранаучным заявлениям, однако должен признать что и бюллетень вызывает у меня не менее скептические ощущения. "Развенчивать" - это конечно благородная затея, но мне кажется не самая полезная.
Почему лженаука так популярна? Почему СМИ накидываются на сообщения разного рода "волшебников", люди раскупают книги Фоменко? Бюллетень дает ответ на этот вопрос:

... что у нее[лженауки] нет тормозов. Она, в отличие от науки, может обещать все,что угодно (то, что это обман, и что он когда-нибудь вскроется, не столь важно). Лженауке свойственно манипулировать чудесами – от контактов с пришельцами до получения необыкновенного алмаза, который, полежав немного в пирамиде, «всасывающей космическую энергию», становится значительно тверже обычного. Новоявленные алхимики обещают дешевые материалы в золото и даже получают финансовую поддержку государства! Этот перечень можно продолжать бесконечно.

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

Где популяризация "традиционной", "нормальной" науки? Где книги, которые можно было читать с интересом? Книгу профессора Куна "Легенды и мифы древней Греции" прочитали наверное миллионы человек. Почему? Потому что она была интересна! Где фильмы, популяризирующие науку? Рассказывающие о научных достижениях?

Известно, что люди любят то, что интересно. Неужели настоящая наука не может быть "подана" так, чтобы заинтересовать потенциального читателя, зрителя слушателя?

Я прошлой зимой был в Московском Политехническом Музее на экскурсии "От Абака до Компьютера". На экскурсии присутствовало 4 человека, считая меня. Да,да - 4 человека. Это и понятно - экскурсия не интересная, и даже я бы сказал скучная. Неужели о рождении компьютеров нельзя рассказать интересно? Книгу о том как работает компьютер Чарльза Петцольда "Code: The Hidden Language of Computer Hardware and Software" лично я читал запоем. А книга кстати вполне годится для школьников старших классов. А после прочтения подобных книг сразу уничтожаются мысли о том что кмопьютерный вирус может заразить человека.

А неужели физика или история такие скучные науки что ничего интересного о них рассказать нельзя? И интересно только читать академика Фоменко и господина Акимова?

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

Цветы жизни

2007-03-27T07:55:00.000+04:00

Фаркаш Бояи, венгерский математик, отец одного из "опровергателей" пятого постулата эвклида и создателя неэвклидовой геометрии Яноша Бояи писал своему сыну:

"... для некоторых вещей существуют эпохи, когда они появляются одновременно во многих местах, совершенно как фиалки, которые ранней весной выходят на свет отовсюду".

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

Вот например сегодня сразу пара материалов на очень близкие темы попалось мне под руку. Почитайте в любом порядке:

Why nerds are unpopular? - статья Пола Грэма
Человеководство и компьютер - статья Михаила Ваннаха в Компьютерре

Только просьба - не обращайте внимания на частности - пробуйте найти что-то общее между всеми этими ... "источниками".

P.S. О Фаркаше и Яноше Бояи можно прочитать в книге "Три судьбы" Анны Ливановой. Книгу эту я в интернет магазинах не нашёл, зато нашёл её оформленной в виде курсовой работы вот тут.

Portable Skype

2007-03-22T03:32:00.000+03:00

Я давно пользуюсь Miranda в качестве Instant Messenger. При этом Miranda у меня находится на USB-винчестере. Все это очень хорошо и удобно, но вот последнее время мне часто приходится использовать Skype. Соответственно я скачал плагин, позволяющий использовать Skype прямо из Miranda. И все бы хорошо, но Skype приходится инсталлировать, и к тому же настраивать, на каждом из используемых компьютеров.

Сегодня я выяснил - сам не понимаю, как я об этом раньше не знал, что Skype вполне может быть portable.

Очень просто - копируешь skype.exe в любой каталог на USB-диске или flash-ке, и запускаешь вот так:

skype.exe /datapath:"путь к каталогу где будут жить настройки" /removable

где datapath указывает на каталог где будут жить все настройки. И все работает. Плагин для Miranda тоже можно настроить так, чтобы он использовал не стандартный Skype, а portable:

Кстати вот тут: Skype Command Line Options почему то эти опции не описаны.

Вот так вот. Если я тормоз, а все это и так уже знают - прошу прощения за баян.

Год	Потери
2004	$200млн.
2005	$300млн.
2006	$400млн.