пятница, декабря 14, 2007

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

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

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

четверг, декабря 06, 2007

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

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

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

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

  • Компании, не устанавлювающие никаких ограничений по возрасту
    1. Яндекс
    2. Google.Россия
    3. Дизайн Студия Артемия Лебедева
    4. CQG
    5. Люксофт
    6. Quest Software (Moscow)
    7. IBM Россия
    8. РБК Медиа
    9. EGAR
    10. Acronis
    11. CBOSS
    12. Deutsсhe Bank Россия
  • Компании, устанавливающие ограничения
    1. Крок - в среднем ограничение возраста 23-35 лет
    2. Результаты поиска в группе форумов RSDN ( Программирование :: Работа):
      "По запросу '"возраст до" | "Возраст до"' найдено документов: 51".
Ну что тут сказать. Конечно эта статистика не полна и спорна. Тем не менее видно, что возрастных ограничений не так уж и много. По каким причинам возникают возрастные ограничения для программистов?

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

  2. Довольно распространённое мнение, что если после какого-то возраста человек ещё не стал "начальником", то значит он неудачник или недостаточно квалифицирован, а значит "нам не нужен".

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

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

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

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

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

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

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

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

Экономия

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

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

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

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

среда, декабря 05, 2007

Here comes another bubble ...

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

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

вторник, ноября 27, 2007

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

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

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

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

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

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

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

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

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

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

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

пятница, ноября 09, 2007

Ещё вопросы

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

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

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

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

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

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

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

четверг, октября 18, 2007

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

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

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

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

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

  1. WhatTheFont - web-приложение, которое позволяет загрузить картинку и автоматически пытается определить шрифт. Изображение нужно сначала специальным образом подготовить (подробные инструкции есть на сайте)

  2. Identifont , ITC Fonts, Fonts.com - содержат небольшую "экспертную" систему, которая задаст некоторое количество вопросов про интересующий шрифт и выдаст список наиболее подходящих шрифтов

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

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

  5. FineReader или другая полноценная программа распознавания текста. Все в них хорошо, кроме того что при их использовании не покидает ощущение стрельбы из пушки по воробьям.
Мой выбор - (4) - Kleptomania - самая удобная, быстрая и к тому же бесплатная программа.

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

четверг, октября 04, 2007

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

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

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

понедельник, сентября 24, 2007

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

Недавние мои собственные посты на темы "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 улетает с Альтаира?

вторник, сентября 18, 2007

amazon.com

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

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

17458907.48319b4763d4aa2700c0fda3363b9fab.1190107741.d9c1ec9c770af938959863dd60b588c0

воскресенье, сентября 16, 2007

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

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

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

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

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

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

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

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

  2. Поиск: И к тому же при помощи современных средств хранения информации можно ещё и найти что-нибудь в этом море информации.

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

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


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

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

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

  • Мы пытаемся решить проблему надёжности бесконечным копированием информации (созданием "резервных" копий), потому что на самом деле другого способа нет

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

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

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

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


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

среда, сентября 12, 2007

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

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

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

Примерами носителей могут быть и бумага, или 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, магнитные барабаны, лампы), а часть конечно просто забыта. Во всех ошибках или неправильных описаниях, виноват конечно же я,был бы благодарен за любые дополнения и уточнения.

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

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

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

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

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

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

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

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

среда, сентября 05, 2007

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

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

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

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

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

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

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

  2. Instant Messaging:
    • Miranda: тут у меня и ICQ и MSN и Gtalk и AIM - все instant messengers, которыми я пользуюсь
    • Skype: пока что я не увидел толкового плагина skype для миранды, поэтому skype стоит сам по себе. Поставил, как только понял что можно заставить его быть "portable"

  3. Browsers:
    • Portable Firefox - браузер которым я пользуюсь практически постоянно, естественно достаточно нафарширован плагинами. Очень удобно пользоваться "запоминалкой паролей" и вводить ничего не надо и на самом деле твои пароли всегда с тобой.
  4. WinScp - SFTP клиент; он правда хранит настройки в registry, но я их экспортирую

  5. Утилиты от Mark Russinovitch
    • Autoruns
    • DbgView
    • ProcessExplorer
    • ProcessMonitor

  6. Orca - кто разрабатывал инсталляционные процедуры для Windows Installer, тот знает :-)

  7. Araxis Merge - лучшая, на мой взгляд, Diff/Megre программа. На самом деле тоже хранит настройки в registry, но с этим можно смириться

  8. EditPlus - "легкий" текстовый редактор с подсветкой синтаксиса. Кнопка F4 у меня в TotalCommander настроена именно на него

  9. OllyDbg - отладчик :-)

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

17458907.48319b4763d4aa2700c0fda3363b9fab.1188990934.a3319c942a5192f6e66ca91f6f9e104c

пятница, августа 31, 2007

Архивы в сети

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

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


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

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

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

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

воскресенье, августа 19, 2007

Про типы

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

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

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

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

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

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

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

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

  • Деревенскому брадобрею приказали «брить всякого, кто сам не бреется, и не брить того, кто сам бреется», как он должен поступить с собой?

  • В одной стране вышел указ: «Мэры всех городов должны жить не в своем городе, а в специальном Городе мэров», где должен жить мэр Города мэров?

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

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

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

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

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

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

суббота, августа 04, 2007

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

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

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

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

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

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

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

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

Замечания

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

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

17458907.195e50a0db7e7428ccd693c67f635406.1186223110.9626a2d31cf793845f340f27c23ea8b8

пятница, августа 03, 2007

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

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

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

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

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

  1. Стиль и синтаксис форматирования исходного кода программы
    • Расстановка скобок
    • Использование пробелов и пустых строк
    • Правила написания выражений (for, if, while и так далее)
    • Правила именования переменных
    • Правила объявления переменных
    • Правила написания комментариев
    • Правила использование отступов
  2. Иногда к содержанию первого пункта могут быть добавлены элементы "управления конфигурацией"
    • правила именования файлов
    • структура файлов проекта
    • правила использования системы контроля версий
    • стандартизация используемых средств разработки
  3. Иногда к стандартам кодирования могут также быть добавлены "best practices" того, как надо писать программы, в зависимости от определённого языка программирования, среды разработки, компании или специфики разрабатываемого продукта (типичным примером может служить требование "всегда создавать в классе виртуальный деструктор", для C++)
Конечно же, "стандарты кодирования" могут включать в себя содержимое и всех пунктов сразу, и какую-то их смесь, а также что-то что здесь не упомянуто.

Мой взгляд

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

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

Основной необходимостью существования "стандартов кодирования" обычно называют (некоторые части процитированы по Code Conventions for Java Programming Language, они отмечены '*'):
  1. Необходимость работ над одним и тем же исходным файлом нескольким программистам
  2. Улучшение "понятности" исходного кода, что позволяет программистам более полно и быстро понять новый для них код (*)
  3. Необходимость сопровождения (исправления ошибок, внесения небольших исправлений) кода и тот факт что в большинстве случаев споровождение осуществляется не тем же человеком, который является исходным автором кода. (*)
  4. Программист, работающий над исходным кодом, который написан не в "любимом" или "привычном" стиле будет тратить на его исправление больше времени (аргумент Bill Venners из исходного сообщения в форуме).
Моё мнение состоит в том, что усилия на создание и поддержание "стандартов кодирования" в большинстве случаев существенно выше чем затраты на "понимание" или поддержку кода, написанного "в другом стиле". Я конечно не имею ввиду примеры из "Obfuscated C Code Contest" :-) В большинстве случаев, код написанный вменяемым программистом понятен другому вменяемому программисту, вне зависимости от того, как именно расставлены в нем фигурные скобки или именованы переменные. Единственной неприятностью могут быть различия в настройках отступов и табуляций/пробелов, при просмотре кода различными текстовыми редакторами, просмотрщиками и программами сравнения.

Поэтому в моей голове всегда существовал такой "стандарт кодирования":
  1. Единообразная настройка длины табуляции (tab length)
  2. Использование пробелов вместо табуляций
  3. При правке кода пользоваться тем стилем, который используется в этом коде
Вот собственно и все. А если Вы или Ваш коллега пишете код в стиле "Obfuscated C Code Contest", то подумайте может проблема должна быть решена не при помощи "стандартов кодирования", а как-нибудь по-другому?

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

вторник, июля 31, 2007

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

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

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

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

Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Это:

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

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

17458907.195e50a0db7e7428ccd693c67f635406.1186148117.6d2ce9534a9cad439ee9664a6e39399e

суббота, июля 28, 2007

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

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

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

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

  1. Билл Брайсон. "Краткая история почти всего на свете"
  2. Л.Б. Вишняцкий. "История одной случайности или происхождение человека"
  3. Владимир Сурдин "Астрология и наука"
  4. Владимир Сурдин "НЛО: записки астронома"

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

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

суббота, июля 14, 2007

Аэропорт

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

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

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

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



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

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

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

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

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

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

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

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

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

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

Мел кивнул.

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

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

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

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

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

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

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

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

суббота, июля 07, 2007

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

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

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

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

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

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

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

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

  2. Совещания, которые необходимы для определения 'общего направления', создания 'единого видения', 'одинакового понимания' и тому подобного

  3. "Регулярные" совещания. Еженедельные "status meetings" и так далее

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

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

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

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

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

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

  2. Реальный статус проекта начальник может узнать непосредственно у подчинённого ("в рабочем порядке"), для этого нет необходимости созывать всех и заставлять каждого слушать ответы остальных и ждать своей очереди. (Хочу обратить внимание, что если у начальника слишком много подчинённых, то это само по себе является проблемой. Оптимальное количество подчинённых, по всей видимости, является равным оптимальному количеству сущностей, которыми может одновременно оперировать человек, то есть 7+-2 G. Miller. Magical Number Seven)

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

  4. Очень часто подобные совещания носят ритуальный характер (то есть совещания в которых важна сама форма поклонения боссу). Если подобные совещания нужны начальнику для поддержания собственной значимости, то не совсем понятно стоит ли это того, чтобы тратить столько времени подчинённых (взято из Tom DeMarco, Timothy Lister Peopleware: Productive Projects and Teams)

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

вторник, июля 03, 2007

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

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

воскресенье, июня 24, 2007

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

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




[Если быть совсем точным, то уж по настоящему первым языком программирования была, по всей видимости, та нотация, с помощью которой были написаны программы Чарльза Бэббиджа в знаменитой статье Ады Августы Байрон, графини Лавлейс "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 не оказал существенного влияния на другие языки. Но тем не менее историческое первенство - за ним.

четверг, июня 14, 2007

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

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

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

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

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

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

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

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

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

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

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


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

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