Программисты ошибаются. Компьютеры тоже…

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

Рассказывают, что в Америке в одной из вычислительных лабораторий на видном месте стоит небольшая витрина, на которую прилеплена бумажка с надписью весьма близкой по смыслу к встречающемуся в отечественных автобусах призыву: “При аварии разбить стекло молотком”. А в витрине лежат… счеты. Обыкновенные конторские счеты – далекий предок нынешних компьютеров. Смешно? Безусловно. Однако, как говорится, в каждой шутке есть доля… шутки, и призыв лишний раз перепроверить результаты компьютерных вычислений, пусть даже и при помощи счетов, не покажется столь уж абсурдным, если знать, к каким последствиям может привести ошибка при работе компьютера.

Компьютер непогрешим. Эта мысль, благодаря первым популяризаторам вычислительной техники и нынешней рекламе, прочно закрепилась в умах людей, уверенных в том, что уж “машина-то не подведет”. Увы, это неправда. Компьютеры ошибаются. И делают это достаточно часто. По крайней мере, гораздо чаще, чем того хотелось бы разработчикам. “Самый надежный компьютер – выключенный компьютер”, – шутят по этому поводу программисты. И их правоту подтверждает череда ошибок и сбоев, сопровождающих работу практически любой вычислительной системы.

Когда возник самый первый компьютерный сбой, доподлинно не известно (скорее всего, в первый же день после запуска вычислительной машины), зато можно точно сказать, что термин “bug”, обозначающий сбой системы, был введен в обиход в 1943 году. Случилось это в Америке, когда в компьютер Mark-II, использовавшийся военно-морскими силами США для баллистических расчетов, неведомо каким образом залетел мотылек. Пустяковое событие привело, однако, к плачевным последствиям. Бедное насекомое ценой собственной жизни вывело из строя вычислительную систему, закоротив контакты одного из бесчисленных реле внутри вычислительного “монстра”, и тем самым… вошло в историю. Грейс Мюрей Хоппер, работавшая в то время на Mark-II, позже так вспоминала об этом случае: “Когда к нам зашел офицер, чтобы узнать, чем мы занимаемся, мы ответили, что очищаем компьютер от насекомых (debugging). Термин “debugging” (отладка) с тех пор прижился и стал использоваться для обозначения поиска неисправностей в компьютере, особенно в программном обеспечении”. Ну а термин “bug” стал обозначать сбой в работе системы.

На первых порах основной причиной отказов вычислительных систем была ненадежность аппаратуры. Да по-иному и быть не могло. В том скопище десятков тысяч отдельных электронных и механических элементов, которое представляли собой первые ЭВМ, на протяжении рабочего дня почти наверняка находился хотя бы один слабый элемент приводивший к неполадкам в работе, а потому безотказная работа машины в течение достаточно длительного времени воспринималась едва ли не как чудо. Со временем, однако, “железо” стало более надежным, а вот программы… Программы по-прежнему пишутся людьми, а потому неизбежно содержат ошибки. Людям, увы, свойственно ошибаться…

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

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

Самый дорогостоящий дефис в истории

Одной из первых дорогостоящих (в буквальном смысле) компьютерных ошибок стала та, из-за которой американцы потеряли космический корабль-зонд Mariner-1, направляющийся к Венере. Случилось это в 1962 году. Ракета-носитель стала отклоняться от расчетной траектории сразу после старта с космодрома на мысе Канаверал. Пришлось руководству NASA принять решение о подрыве носителя, поскольку ракета вполне могла упасть на населенную территорию. Как результат – срыв программы космических исследований и фейерверк стоимостью в 80 миллионов долларов, именно во столько обошлось создание космического корабля. Конечно же, стали искать виновных. И вскоре выяснилось, что все дело было в одном-единственном дефисе. Его просто-напросто пропустили при подготовке текста программы для ввода в компьютер, управлявший полетом ракеты. Кстати, программа была написана на языке ФОРТРАН, а злополучный дефис, по выражению известного писателя-фантаста Артура Кларка, стал “самым дорогостоящим дефисом в мире”. Все-таки 80 миллионов долларов…

Кстати, еще одна неприятность с ракетной техникой, обусловленная ошибкой в программном обеспечении, случилась уже в 90-х годах. На этот раз пострадали бравые американские военные ракетчики, принимавшие участие в операции “Буря в пустыне”. К их удивлению, ракеты “Пэтриот”, использовавшиеся для перехвата в воздухе иракских ракет, периодически проходили мимо цели. Разбирательства начались после того, как пропущенная иракская ракета привела к гибели 28 американских солдат. Первоначально зародилось подозрение, что часть “Пэтриотов” технически неисправны. Однако созданная по этому поводу комиссия с удивлением обнаружила, что все обследованные ракеты абсолютно работоспособны. Вы уже, наверное, догадались, где пряталась ошибка? Конечно же, в программном обеспечении, использовавшимся американским зенитно-ракетным комплексом. Выяснилось, что система создавалась в расчете на то, что время ее непрерывной работы не будет превышать 14 часов, однако на практике комплексы непрерывно работали по 100 и более часов. Вроде бы пустяк, но оказалось, что используемое для определения времени программное обеспечение накапливало ошибки. За 100 часов работы набегала разница в 0,34 секунды. Программисты, оказывается, знали об этом, да посчитали факт несущественным...

Убийцы в белых халатах

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

И связана она с разработанным компанией Atomic Energy of Canada Limited (AECL) медицинским аппаратом Therac-25, использовавшимся для радиационной терапии больных раком. Как и в предыдущих случаях, программное обеспечение злополучного аппарата содержало ошибки. В результате этого в период с 1985 по 1987 год несколько десятков больных, проходивших лечение на Therac-25, получили повышенную дозу радиации, а для четырех из них врачевание под управлением компьютера и вовсе закончилось трагически.

Проведенная по настоянию родственников независимая экспертиза показала, что причиной стали допущенные программистами AECL ошибки. Причем кое-что, по признанию самих производителей, конечно же, было отловлено на стадии разработки, а вот “несущественные”, с точки зрения инженеров компании, ошибки в программном обеспечении все-таки остались. Нэнси Левинсон (Nancy Leveson) и Кларк Тернер (Clark Turner), проводившие независимое расследование, записали в своем отчете: “Главный вывод из случившегося – концентрация внимания на отыскании в программе отдельных ошибок не гарантирует однозначной работоспособности системы в целом”.

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

90-е годы: череда ошибок

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

Одним из первых сбоев компьютерной системы, который ощутила на себе целая страна, стал сбой в работе компьютерной системы обработки междугородных звонков компании AT&T в 1990 году. Из-за этого абоненты компании почти на 9 часов лишились возможности звонить в другие города и страны, а сама неисправность стала едва ли не крупнейшей за всю историю существования этой телекоммуникационной компании. Поиск ответа на вопрос, почему же произошел сбой в работе системы, в конечном счете, вывел на одну-единственную строчку программного кода, которая и стала причиной возникшего отказа. Увы, шутливое высказывание о том, что всякая программа содержит, как минимум, одну ошибку, в очередной раз получило практическое подтверждение.

В 1994 году эстафету “программных ошибок” подхватила компания Intel. Неполадки в работе нового процессора, получившего имя Pentium, обнаружил профессор Томас Найсли (Thomas Nicely) из Линчбургского колледжа (Lynchburg College) в Вирджинии. Вот уж воистину в чужом глазу и песчинку заметим… Дело в том, что сбой работы процессора происходил лишь при весьма специфических условиях во время выполнения операций с плавающей точкой, и большинство обычных пользователей вообще никогда бы не столкнулись с этой проблемой.

Однако руководство компании Intel приняло эту информацию, что называется, близко к сердцу. Директор по маркетингу Ричард Дракот (Richard Dracott) объяснил это тем, что наличие ошибок может отрицательно сказаться на имидже продвигаемой на рынке марки процессоров Pentium. В результате Intel обязалась заменить всем желающим процессоры с обнаружившимися ошибками на новые образцы, управляющий код которых не содержал багов. Все это обошлось компании в кругленькую сумму (что-то около 450 миллионов долларов), а Intel с тех пор стала публиковать списки обнаруженных ошибок для всех своих чипов.

Следующая неприятность, связанная с ошибками в программном обеспечении, приключилась в 1995 году. На этот раз из-за программистов вовремя не был открыт новый… аэропорт! Но обо всем по порядку. В 1995 году в городе Денвере должен был открыться международный аэропорт, который пресса восторженно называла “аэропортом XXI века”. Предусмотренная проектом система обработки грузов поражала воображение: прием, отправка и сортировка багажа должны были производиться в автоматическом режиме, практически без участия человека. Увы, при испытаниях выяснилось, что роботизированные тележки натыкаются на стены, а грузы сортируются далеко не так, как того хотелось бы разработчикам. Причина – ошибки в программном обеспечении, использовавшемся для управления системой. Как следствие, аэропорт был открыт на 16 месяцев позже намеченного срока, что привело к убыткам, оцениваемым специалистами в размере, как минимум, 3,2 миллиарда долларов. Кстати, багаж в Денвере по-прежнему обрабатывается при участии людей. Доверить столь ответственное дело компьютерной системе администрация аэропорта побоялась. Как говорится, береженого Бог бережет...

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

Впрочем, для коммерческих программ чаще всего все ограничивается выпуском “заплаток” или “патчей” (patch) для устранения ранее выявленных ошибок. Особенно этим славятся программисты Microsoft, редкая программа которых обходится без десятков, а то и сотен “заплаток”. Причем официальные представители Microsoft признаются, что вся их новая программная продукция поступает в продажу с некоторым количеством недоработок. Так, например, по просочившимся в печать сведениям, Windows-2000 на момент выхода в свет (17 февраля 2000 года) содержала более 60 тысяч (!) ошибок и недоделок. Как тут не вспомнить историю, произошедшую в свое время с академиком А. Ф. Иоффе. Рассказывают, что инженерная работа Абрама Федоровича началась с ремонта ветхого моста.

Только что окончивший институт инженер-технолог сразу предложил план ремонта, благодаря которому мост можно было не только починить, но и привести в состояние, при котором он простоял бы десятилетия, вообще не требуя никакого ремонта. Реакция начальства была неожиданной. “Да что вы, сопляк, мелете! – возмутился руководитель будущего академика. – Ведь в этом случае все возможности ремонта будут исчерпаны и нам придется жить на одно жалованье!”. Не иначе, что и программисты зачастую руководствуются тем же принципом. А то ведь к полностью отлаженной программе никаких “заплаток” писать не придется…

В 1996 году отличились французы. Из-за ошибок в программном обеспечении 4 июня был прерван полет космической ракеты Ariane 5. Убытки в результате составили более 500 миллионов долларов. А причина крылась в том, что по недосмотру переменная, которая описывала горизонтальную скорость ракеты, была представлена целым 16-битным числом. В результате, как только эта значение переменной превысило 32 768 (2 в 15-й степени), система управления ракетой, что называется, “подвисла”, а “сошедшую с ума” ракету пришлось уничтожить.

В 1998 году ошибки в программе едва не привели к массовому отключению потребителей электричества в Калифорнии. Случилось это, когда двум новым диспетчерским компаниям, ответственным за перераспределение электроэнергии между ее производителями и потребителями, потребовалось подключиться к уже имевшейся системе диспетчеризации. Для этой цели по их заказу была разработана новая диспетчерская сеть и создано специальное программное обеспечение, позволявшее одновременно работать с 200 электростанциями. Все было готово к пуску 1 января 1998 года. На свое счастье, заказчики догадались “обкатать” программу в тестовом режиме и… отложили запуск проекта на 3 месяца. Именно столько времени потребовалось для окончательной отладки вскрывшихся при тестировании ошибок в программном обеспечении, которые могли бы привести к катастрофическим последствиям для всей сети электроснабжения Калифорнии. К слову сказать, убытки заказчиков из-за задержки с пуском системы были оценены в 90 миллионов долларов.

Ошибка века

Говоря о многочисленных случаях “ляпов” в программном обеспечении, конечно же, нельзя обойти вниманием еще одну ошибку, которая терзала умы программистов в течение по крайней мере пяти последних лет ушедшего ХХ века. Речь, как вы уже, наверное, догадались, идет о пресловутой “ошибке 2000 года”, получившей название Y2K. Для ее исправления была создана целая индустрия, дельцы которой получили немалые прибыли, играя на страхе пользователей перед надвигавшимся компьютерным безумием. По всему миру на предотвращение “ошибки 2000 года” было потрачено около $200 млрд. Но, как говорится, пронесло. А суть проблемы состояла в том, что по утвердившемуся еще в 70-х годах обыкновению для обозначения порядкового номера года использовались всего лишь две цифры. Следовательно, при наступлении 2000 года тысячи компьютеров по всему миру не смогли бы отличить 2000 год от 1900. Для домашней “персоналки” это не так уж и страшно, а вот для банковских, транспортных и прочих систем, жестко привязанных к текущей дате, такая “оплошность” могла дорого обойтись.

Впрочем, несмотря на все предпринятые для исправления ошибки меры, кое-какие неприятности случились. Причем начались они еще до наступления 2000 года. Скажем, в Филадельфии в ноябре 1999 года несколько сот человек получили повестки из суда, обязывающие их явиться в суд в… 1900 году. А более 30 тысяч американцев с удивлением обнаружили в почтовых ящиках официальные уведомления из Управления социальной защиты США о том, что их пенсионные удостоверения подлежат замене, так как в 1900 году срок их действия истекает.

Впрочем, ничего глобального в связи с “ошибкой 2000 года” так и не произошло, хотя некоторые “несообразности”, связанные с этой ошибкой, время от времени давали о себе знать в течение всего 2000 года. Так, например, сбой, связанный с проблемой 2000 года, в информационной системе норвежской национальной железнодорожной компании NSB, произошел с опозданием на год. Утром 31 декабря 2000 г. ни один из новых поездов компании не смог вовремя выйти из депо.

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

Все бы ничего, да вот только мало кто из пользователей знает, что Y2K скорее всего еще вернется. Причина в том, что, по словам специалистов, в 80% компьютерных систем мира для предотвращения кризиса 2000 года применена мера, дающая лишь относительно краткую “отсрочку исполнения приговора”.

Вместо того чтобы просто расширить формат даты, используемый для представления года, с двух до четырех цифр, во многих случаях применен “сдвиг временного окна”. Этот нехитрый трюк, позволяет программе “догадаться”, относится дата к XX веку или к XXI. Как правило, номера лет из первой части поддерживаемого диапазона (например, от 0 до 30) считаются относящимися к новому интервалу дат, а остальные, например, 87 – к прежнему. Ясно, что мера эта временная и через каких-нибудь 30-40 лет “проблема 2050 года”, что называется, встанет в полный рост. Между прочим, и в 70-е годы тоже казалось, что до XXI века еще уйма времени...

Вместо заключения

Забавно, но один из методов проверки программы на содержание ошибок состоит в том, что в уже готовую и отлаженную программу нарочно вносятся… дополнительные ошибки. Удивлены? А нет тут ничего удивительного. Просто тестируемую программу с заранее внесенными ошибками дают на отладку программисту, который и пытается восстановить ее работоспособность. Если обнаруживаются лишь нарочно внесенные ошибки, то считается, что исходная программа ошибок не содержит. А вот если при поиске “эталонных ошибок” обнаруживаются и неизвестно откуда взявшиеся дополнительные недочеты, то программа, увы, должна быть признана сырой. Хороший метод. Надежный. Да вот только, как это замечено в одном из законов Мэрфи, “ошибки порождают новые ошибки”. Может, оттого и множатся ошибки в уже готовых программах?

Источник: Атлант

День программиста

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

Стоит отметить, что День программиста, начиная с июля 2009-года, приобрёл государственный статус согласно указу Президента РФ Дмитрия Анатольевича Медведева. В июле этого года на рассмотрение Правительства Министерством связи и массовых коммуникаций Российской Федерации был подготовлен и внесён проект Указа Президента России «О Дне программиста».

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

Вы по прежнему можете заказать у меня программы на заказ, несмотря на то, что сегодня День программиста!

Видео с риан.ру про программистов: "Кто такой программист, или Отличительные особенности "вида":




P.S. У меня нет хвоста и бороды :-) То есть видео для юмора.

Также я писал про День программиста в прошлом году.

О влиянии кризиса на рынок фриланса

Интересная публикация об удалённой разработке была опубликована на "Вебпланете" с названием: "Free-lance.ru: "Крупные заказчики созрели". В ней рассказывается о влиянии кризиса на рынок фриланса, интервью с Василием Воропаевым, основатель проекта free-lance.ru.

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

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

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

Полный текст новости можете прочитать здесь http://webplanet.ru/interview/life/2009/09/09/freelance.html

Google Developer Day 2009 в России

Как сообщается на главной странице Google Code, Google Developer Day возвращается в Россию! Это конференция на 1 день для веб-разработчиков, и она в 2009-м году пройдёт в Москве 10 ноября.

В предыдущем, 2008-м году в GDD приняли участие свыше 400 разработчиков из более чем 50 городов Российской Федерации и ближнего зарубежья. Они смогли посетить полтора десятка семинаров и сессий по всем девелоперским продуктам Google. В этом году опять представится возможность живого общения с командами Google, работающими над API (Application Programing Interface, Интерфейс программирования приложений) и инструментами для веб-разработчиков и программистов. На конференции выступят инженера Google с подробными докладами. Много времени будет выделено для знакомства программистов друг с другом и обсуждения новейших веб-технологий.

Сайт GDD, как обещается, будет запущен в самое ближайшее время, на нём можно будет зарегистрироваться для участия в Google Developer Day.

Источник: http://code.google.com/intl/ru/

Microsoft поддержит российских разработчиков программного обеспечения

Корпорация Microsoft решила предоставить скидку в 80% разработчикам программного обеспечения, которые делают программы среде Microsoft Visual Studio.

Как говорится в пресс-релизе, в новой программе поддержки и развития бизнеса разработки программного обеспечения в России смогут участвовать индивидуальные разработчики и небольшие компании, у которых штат программистов не превышает лимита в 10 человек. В течение всего времени с начала акции 28-го июля по 31-е августа 2009-го года можно будет приобрести лицензии на студию с 80% скидкой.

На момент написания этого поста было свободно 2147 лицензий из общего количества предосталяемых 3500.

Пресс-релиз здесь: Инициатива по лицензированию разработчиков ПО

С днём системного администратора - Happy SysAdmin Day!

Каждый программист хотя бы немного и системный администратор. Он сам устанавливает Linux, настраивает Apache, MySQL и PHP чтобы собрать ту самую лампу (LAMP) для веб-разработки. Также, при разработке приладного программного обеспечения, нельзя обойтись без навыков системного администрирования, настройке сетей и прочих вещей, прямо к программированию не относящихся, но являющихся столь необходимыми.

Сегодня последняя пятница июля 2009 года, и сегодня системные администраторы всего мира отмечают День сисадмина.

Согласно Wikipedia, «Отцом» праздника всех системных администраторов является сисадмин из США с 20-летним стажем Тед Кекатос, который решил, что хоть раз в год системные администраторы должны чувствовать благодарность со стороны пользователей. Первый раз данный праздник был отмечен 28 июля 1999 года. Это был просто пикник на природе на окраине Чикаго, в котором приняли участие члены небольшой софтверной компании.

Тетрису 25!

Сегодня, 2-го июня 2009-го года знаменитой электронной игре Тетрис официально исполнилось 25 лет. За эти годы по всему миру было проданы несколько десятков миллионов тетриса официально, а ещё больше копий неофициально разошлось по пользователям для самых разных электронных платформ.

Автором Тетриса является Алексей Пажитнов (Alexey Pazhitnov). Он в 1984 году работал программистом в Вычислительном центре Академии наук СССР. В связи с его и многих других его коллег головоломками он решил написать для советской ЭВМ "Электроника-60" простую вариацию на тему головоломки пентамино, в которой надо было складывать фигуры из двенадцати элементов, каждый из которых состоит из пяти квадратиков.

Однако, так как вычислительной мощности компьютера хватило лишь на игру с тетрамино - фигурками из четырех квадратиков, то место 12 фигур получилось только семь. Тем не менее, результат его программистских трудов оказался настолько захватывающим, что Тетрис быстро распространился в среде советских программистов, а впоследствии был переписан для использования на компьютерах IBM PC и попал в страны соцлагеря, благодаря чему он стал известен в странах Запада.

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

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

Так вот, были бы компьютеры тогда помощнее, не было бы тетриса, был бы какой-нибудь пентис :-) .

Видео на тюбике: Первое в истории видео Алексея Пажитнова (Алексей Pazhitnov), создателя Тетриса на его встрече с Хенком Роджерсом, в СССР.

Русские хакеры изменили представления Запада о России

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

«Водка, мороз, медведи, матрешки, шапки-ушанки – все это осталось в прошлом. Кардеры, фишеры, хакеры, дешевые скрипты, теневые схемы, валютчики, WebMoney – вот то, с чем ассоциируется Россия теперь», – такое заключение делает Ecommerce Journal, пытаясь разобраться в хитросплетениях загадочного русского характера.

По мнению авторов издания, русские любят ICQ, не любят телефонные переговоры, а в делах ценят красоту и быструю прибыль. Всем, кто планирует вести бизнес с русскими, издание рекомендует не поддаваться стереотипам прошлого. Прежде всего следует учитывать, что бизнес для большинства россиян имеет смысл, если он приносит прибыль свыше 50%, а иногда и 100%, отмечает Ecommerce Journal. Обсуждая с русскими интересный, но сложный проект с прибылью 20%, следует ожидать отказ: российские партнеры не любят ждать, они предпочитают работать по-крупному, даже с инвестициями, продолжает издание.

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

"Типичные русские не любят разговоров по телефону, предпочитая MSN, Yahoo, QQ, Skype одну единственную программу – ICQ. Причем вычислить их можно по нескольким признакам: адрес на Gmail, лог с зафиксированными IP-адресами экзотических стран и пяти- или шестизначный номер ICQ, - пишет Ecommerce Journal. - Россияне также не любят усложнять жизнь бумажной волокитой, избегая документов и формальности. В некоторых случаях они могут просто не понять предложение оформить партнерские отношения на бумаге".

Главное правило коммуникации с партнерами из России – никогда не настаивать на телефонных переговорах, отмечает Ecommerce Journal. "Конечно, ваш партнер знает английский, причем достаточно хорошо для того, чтобы обсудить с вами множество моментов, но если вы делает бизнес в Сети, помните, что российские IT-специалисты рассматривают коммуникацию в тесной связи с интернет-протоколами", - пишет издание.

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

www.vz.ru

Составлен список самых опасных ошибок в программировании

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

Инициатором проекта стал SANS Institute, а в работе приняли участие эксперты из Агентства национальной безопасности США, Microsoft, Symantec и других компаний, университетов и организаций. В составленном ими списке фигурируют такие оплошности программистов, как возможность осуществления инъекций SQL, межсайтового исполнения сценариев, пересылка секретной информации в текстовом виде и задание паролей непосредственно в коде программ, где их трудно поменять в случае раскрытия. В прошлом году пара ошибок из этого списка дала возможность взломать свыше 1,5 млн Web-сайтов.

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

Вред локализации приложений для разработчиков

В предыдущем посте писалось про пользу локализации приложений, однако, как считает всё тот же автор, русификация продуктов для разработчиков программного обеспечения не вносит никаких преимуществ, по сравнению с локлизацией программных продуктов для пользователей. Причиной является поощрение незнания технического английского языка. Следствием этого является низкая отдача от работы программиста, не знающего технический английский, на котором, как известно, поставляется подавляющее большинство качественной технической документации и новостей. В случаях, когда в коллективе никто специально не занимается повышением своей квалификации дополнительным следствием этого является сравнительно более низкая квалификация.
Все слышали оправдание нежелания учить английский – "раньше изучал другой язык (немецкий?), а сейчас уже немолод, семья, дети, работа – на это нет времени". Хотя и с этим можно поспорить. Если же в школе (а тем более – в ВУЗе) человек учил английский – одного года программирования в англоязычной среде (Windows+Visual Studio+MSDN, Linux+GCC+man) достаточно, чтобы больше не задумываться о необходимости их русификации. Думаю, это знакомо каждому.
Про перевод на русский языков программирования я, пожалуй, умолчу. Всем понятно, что с точки зрения бизнеса (зарабатывания денег), локализация продуктов рассматривается как дополнительный источник доходов и наивно полагать, что в будущем откажутся от идеи русифицировать, скажем, Visual Studio и MSDN. Но, на мой взгляд, изучение и знание хотя бы технического английского языка входит в программу-минимум, который должен знать каждый программист.

Полезность глобализации при разработке приложений

Как пишет Олег Аксeнов в своём блоге, глобализация – это процесс проектирования и реализации ПО, предназначенного для использования локализованного UI пользователями разных регионов мира. Вот полный текст сообщения:

Хочу поделиться некоторыми мыслями по поводу глобализации. Разумеется не о глобализации как «процессе всемирной экономической, политической и культурной интеграции» ((с) Wikipedia), а о глобализации приложений :) Недавно обсуждали это на работе, решил поделиться и с вами своими соображениями на этот счет.

Почитать о том, что это такое, какие есть best practices и технологии можно в поиске по MSDN. Если коротко, глобализация – это процесс проектирования и реализации ПО, предназначенного для использования локализованного UI пользователями разных регионов мира. В этом контексте локализация – это процесс перевода ресурсов приложения для всех регионов, которые поддерживает приложение. Для простоты можно считать регионы странами, хотя это не совсем так.

Теперь о моем отношении к этому вопросу.

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

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

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

Помимо этого у меня есть два соображения по поводу пользы использования хотя бы строковых ресурсов даже без локализации:

• Когда строковые ресурсы не «внедрены» в web-приложение, а поставляются в виде отдельных файлов, их можно оперативно скорректировать на рабочем сервере без необходимости полного деплоймента и перезапуска приложения.
• Иногда полезно бывает получить полный список сообщений в системе для review у заказчика, а получить их из одного или нескольких XML-файлов на порядок проще, чем «собирать» их по всему приложению.

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

День программиста

Сегодня 256-й день в году, а значит, сегодня ДЕНЬ ПРОГРАММИСТА.

День программиста является неофициальным праздником программистов, который отмечается на 256-й день года (255-й с нуля). Число 256 (2⁸) выбрано потому, что это количество чисел, которое можно выразить с помощью одного байта. Так же, число 256 в шестнадцатеричной системе счисления имеет представление как 100 (0x100). И так же это максимальная степень числа 2, которая меньше 365. В года, не являющиеся високосными, этот праздник попадает на 13 сентября, a в високосные - на 12 сентября.

День программиста в России также отмечается 22 апреля. Возникновение этой даты непосредственное связано с кодировкой специальности 220400 (Программное обеспечение вычислительной техники и автоматизированных систем). Однако, согласно новой классификации, в России специальность «ПО ВТ и АС» имеет код 230105.65 - появился повод праздновать День Программиста 23 января. Также некоторые считают Днём программиста даты:

• 19 июля - день создания первой программы, которую написала Августа Ада Лавлейс, являющейся первой программисткой и дочерью Джорджа Байрона. Эта программа предназначалась для вычисления чисел Бернулли на аналитической машине английского математика Чарльза Бэббиджа. Заметьте, первой программисткой была женщина :-)
  
• 10 декабря - день рождения первой программистки Ады Лавлейс (1815 г.), в честь которой назвали первый универсальный алгоритмический язык программирования Ada, который был утвержден как раз 10 декабря 1980 г.
• 4 апреля — 4.04, по аналогии с ошибкой 404 («данная страница не найдена»). Считается днем веб-программистов.
• 26 июля - в честь предъявления первого в истории обвинения создателю компьютерного вируса. В 1989 году в этот день уголовному преследованию был подвергнут студент Роберт Моррис, создавший и запустивший компьютерного червя, названного его именем.
• На Украине со времен FidoNet принято отмечать день программиста в "пятницу, 13-го".

Пока День программиста не упомянут в календаре профессиональных праздников России. Ещё в 2002 году программист Валентин Балт, являясь сотрудником веб-студии, составил обращение к Правительству Российской Федерации о признании Дня программиста официальным праздником и даже организовал сбор подписей в поддержку этой инициативы. Однако, до сих пор праздник и не стал официальным.

P.S. Отмечается даже День блога - 31 августа, так как слово Blog похож на цифры 3108, который и представляется как эта дата.

Русские программисты умеют и делают больше :-)

Лет десять тому назад было дело.
Специалисты одного российского научного центра работали по контракту с американской компанией. Из-за рубежа поступило задание — провести тестовые испытания нового компилятора (были переданы программа и методика тестирования) и через неделю представить результаты. В назначенный срок американцы получают отчет о проделанной работе: «Мы проанализировали работу компилятора и методику тестирования и нашли их весьма далекими от совершенства. По нашим расчетам, производительность программы можно повысить на 20-30%. Специалисты уже начали модернизацию компилятора, которая будет завершена через месяц. Спустя еще две недели мы передадим вам отлаженную программу и отчет о ее тестировании».
Многие российские кадровые агентства отмечают в качестве одной из проблем трудоустройства отечественных разработчиков за рубежом их слишком высокий научно-технический уровень подготовки. Точнее, не высокий, а «не соответствующий реальным требованиям». Они знают больше, чем нужно программисту, но при этом не в курсе многих необходимых для работы вещей. У нас, как и раньше, готовят ученых, способных решать уникальные задачи, а не технологов, обеспечивающих работу серийного производства. Технологов применительно к программированию - с точки зрения выражения «программирование — это технология». Технология же подразумевает создание четкой системы разделения труда и следование достаточно жестким стандартам и правилам. Не говоря уже о распределении обязанностей внутри групп программистов, сегодня в отдельные категории специалистов выделились тестеры, технические писатели (документация), сотрудники техподдержки. А обычно в небольших фирмах приходится тянуть всё это хозяйство самим.
По материалам КомпьютерПресс.

Комментарии к бусидо программиста

Текст относится к предыдущему посту "Бусидо программиста" и является комментарием.

Почему в СССР? Как сказал поэт:


"Я люблю эту грешную землю

Потому что другой не видал."

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

1. Использована знаменитая трехшаговая схема Ф.Э. Джержинского. Так же как и в оригинальном высказывании, все рекомендации носят чисто иносказательный характер. Более полно этот принцип звучит так: "Программист должен уметь сидеть за дисплеем по 24 часа в сутки (или по 25/23 - в день осенне-весеннего перевода часов); должен уметь не думать ни о чем, кроме программы, и при игре в ТЕТРИС не задевать ногтем за клавишу ESCAPE (на старой клавиатуре с 84 клавишами)". Наиболее сушественен второй принцип, в своем развитии простирающийся до системы йогов и буддийской техники психорегуляции.

См. также комментарий к принципу 3.

2. "Самурай должен стремиться к смерти. Если есть два пути и один из них ведет к смерти, то самурай должен вступить на путь, ведущий к смерти." Программист работает над программой, пока его начальник не вырвет ее из рук программиста насильно и не объявит официально об окончании работы над программой. (Здесь имеются в виду, конечно, большие программы, а не маленькие. Любопытно исследовать вопрос о том, как с ростом сложности программы она скачкообразно переходит из разряда маленьких программ в разряд больших, или нескончаемых; и далее, по мере дальнейшего усложнения, перескакивает в разряд програмных проектов с непредсказуемам состоянием завершенности.

См. также книгу Ф.Брукса "Мифический человеко-месяц".

3. Коррелирует с второй частью принципа первого. Ни мысли об окончании работ, ни мысли о деньгах или престиже не должны занимать голову программиста даже в режиме Terminate but Stay Resident (Окончиться, но не освобождать память). Память программиста во время работы над программой должна быть полностью отдана программе. Опыт показывает, что любые посторонние мысли в конечном счете только мешают. Что делать, если посторонние мысли все-таки лезут? Или заниматься аутотренингом; или найти работу поинтереснее; или найти, как обойти
данное неинтересное место в программе или сделать его интересным; или ничего не делать с сознанием того, что работаешь медленнее и хуже, чем мог бы; или устоить перерыв.

4. В древности считалось, что программирование начинается с рисования блок-схем. Опыт показывает, что начинать программирование нужно задолго до и кончать значительно позже этапа собственно работы с текстом программы. Этот принцип работы глубок. Что вы, собственно, хотите сказать своей программой? Хватит ли у вас сил, средств и ресурсов? Не написана ли она уже давно другим? Нужна ли она будет кому-нибудь после того, как она примет товарный вид? Сможет ли этот кто-нибудь ее купить, при условии, что вы произвели ее для продажи? И, опять же, если вы преполагаете продавать свою программу, как и за сколько вы будете ее продавать?...

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

5. К этому надо стремиться. В этом состоит подлинное исскуство.

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

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

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

8. Игры, антивирусы, NORTON COMMANDER и прочие резиденты, драйверы ALFA и BETA должны быть удалены из памяти, а то и вообще с винчестера. Это - детские болезни. Что касается игры ТЕТРИС, то это самая лучшая компьютерная игра, но все равно нудная.

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

Одно по-настоящему внимательное прочтение руководства по MS-DOS избавит вас от многих и многих разочарований и неприятных открытий.

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

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

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

13. Чисто стилевой элемент. Иллюстрирует тот факт, что грош цена системе, не имеющей возможности для развития.

Бусидо програмиста на IBM PC

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

Бусидо програмиста на IBM PC
1. Программист должен иметь толстую задницу, пустую голову и коротко остриженные ногти на правой руке.
2. Программист должен стремиться к отладке. Если ситуация имеет два выхода, один из которых - завершить работу над программой, а другой отлаживвать дальше, то программист должен выбирать второй путь.
3. Дата завершения программы невычислима и не постижима. Для спокойствия души программист должен вообще забыть о том, что он когда-нибудь кончит писать эту программу.
4. Программист программирует процесс собственного программирования.
5. Если в вашей программе есть байт, который вам не нравится, перепишите ее всю.
6. Хороша та программа, которая продается. Программа не считается законченной, пока клиент не расплатился.
7. На вопрос: "Можете ли вы написать данную программу?" настоящий программист отвечает одним из двух способов:"Могу" или "Могу, но не знаю как".
8. Нет игр, кроме ТЕТРИСа, да и тот нудянка страшная.
9. Настоящий программист пользуется стандартными средствами. Почти все программы уже давно написаны.
10. Обязательные действия настоящего программиста: распечатывать дампы, читать документацию, дышать, есть и спать. Высший приоритет у сна.
11. Информация аддитивна.
12. Настоящий программист должен иметь четко сформулированное представление о месте программирования в жизни. Например:
- Любое неотложное дело можно отложить на любое неопределенное время. Нельзя откладывать только излишества и развлечения.
- Работа должна напоминать досуг.
- От работы кони дохнут.
- Лучше ничего не делать, чем делать ничего. и т.д.

13. Зарезервировано для дальнейшего развития.

Возможности программиста, невозможности компьютера

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

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

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

В процессе разработки оказывается, что у заказчика полный бардак не только с ведением дел и документации, но и с наплевательским отношением его сотрудников вообще на всё, что происходит на фирме заказчика. Как можно догадываться, никакие SQL, Delphi, Excel и PHP тут не помогут в принципе. И такая "База данных" неожиданно и плавно переходит в некое подобие ERP или CRM:

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

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

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

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

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

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

С уважением, Ильдар Валеев.

Юмор программистов

Автор подборки неизвестен.
Настоящие Программисты не пишут специально - пользователь сам сообразит что ему понравится и возьмет то, что сможет достать.
Настоящие Программисты не комментируют свои программы. Это тяжело написать и потом тяжело прочитать.
Настоящие Программисты не пишут прикладных программ. Они пишут программы для железа. Прикладное программирование - это для слабаков, которые не могут делать системных программ.
Настоящие Программисты не едят quiche. Они едят Twinkies, and Szechwan food.
Настоящие Программисты не пишут на COBOL. COBOL это венец для прикладных программистов.
Настоящие Программисты никогда не пишут программу правильно с первого раза. Но если их бросить на машину, они запросто могут исправлять программу по 30 часов без отдыха.
Настоящие Программисты не пишут на FORTRAN. FORTRAN это как курение опиума при снятии стресса для чудаков и надежда кристаллографии.
Настоящие Программисты никогда не работают с 9 до 5. Если кто-нибудь из Настоящих Программистов и работает около 9 утра, то это только потому, что он работал всю ночь.
Настоящие Программисты не пишут на BASIC. В настоящее время нет программистов, пишущих на BASIC, в возврасте старше 12 лет.
Настоящие Программисты не пишут на PL/I. PL/I это для программистов, которые не могут решить на чем им писать, то ли на COBOL, то ли на FORTRAN.
Настоящие Программисты не пишут на APL. Каждый дурак может не понять APL.
Настоящие Программисты не играют в теннис и не занимаются каким-либо другим спортом, в котором надо переодеваться. Альпинизм - вот это да! И Настоящий Программист ходит в своих горных ботинках и на работу, и при удаче может, внезапно, прыгнуть в середину машзала.
Разработка программного обеспечения, услуги программиста, интересные статьи и книги по программированию.
Настоящие Программисты не докуметируют. Документация это для глупцов, которые не могут читать листинги или объектные модули.
Настоящие Программисты не пишут на PASCAL, или BLISS, или ADA, или каком-нибудь другом научном языке. Строгий контроль типов для людей со слабой памятью.
Настоящие Программисты знают лучше пользователей, что им нужно.
Настоящие Программисты полагают, что структурное программирование это происки коммунистов.
Настоящие Программисты не планируют. Планирование это удел жаб-начальников. Настоящие Программисты любят держать своих начальников в неизвестности.
Настоящие Программисты думают лучше, когда играют в ADVENTURE.
Настоящие Программисты наслаждаются установкой CP/M на 370 машину и MVS на свою ZX81s.
Настоящим Программистам никогда не мешает система безопасности. Они сбрасывают RACF биты и выходят без изменений данных настройки системы безопасности.
Настоящие Программисты никогда не меняют исходники с ZAPs, после всего, завтра он будет менять программу снова.
Настоящие Программисты не тестируют. Тестирование это для людей со слабыми нервами и неуверенных в себе.
Программа Настоящих Программистов всегда рекурсивна и запускается в статусе супервизора, иначе программирование не доставляет настоящего удовольствия.
Настоящие Программисты никогда не делают резервных копий.

Законы Мэрфи - Мысли о программировании

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

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

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

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

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

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

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

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

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

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

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

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

Мозг человека обычно загружен лишь на 10% своей мощности; остальное - резерв для операционной системы.

Программист, как поэт, работает почти исключительно головой.

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

Выдавать глобальные идеи - это удовольствие; искать сволочные маленькие ошибки - вот настоящая работа. ( Брукс )

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

На этот раз программа обязательно пройдет.

Все программисты - оптимисты.

Я только что нашел последнюю ошибку.

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

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

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

Концептуальное единство является самым важным соображением при проектировании системы.

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

Я не знаю причины, по которой нам не следует этого делать, но, возможно, позже мы придумаем какую-нибудь. (Марк Дэвисон)

- Ошибка? Это не ошибка, это системная функция. (Т. Джон Уэнделл)

Компьютер "делает из всех нас дураков".

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

У компьютера всегда есть оправдание; у программиста - никогда. (Марк Дэвисон)

Пользователь не знает, чего он хочет, пока не увидит то, что он получил. (Э.Йодан)

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

На пустом диске можно искать вечно. ( COMPUTERWORLD BUTTON )

Бесполезно придумывать защиту от дурака - ведь дураки так гениальны. (Э.Мэрфи, DEC )

Если отладка - процесс удаления ошибок, то программирование должно быть процессом их внесения. ( Э.Дейкстра )

Вы уже дошли до состояния, когда у вас нет времени, чтобы разрешить те проблемы, которые отнимают у вас все время??? (Марк Дэвидсон)

Опубликовал: Ильдар Валеев

Цена последнего галлона нефти и сверхурочной работы программиста

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

Мое мнение, которое я пытаюсь выразить здесь «сверхурочные в индустрии ПО – зло», причем не только для программистов – кто бы сомневался в этом, это зло для компании, индустрии и экономики в целом.

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

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

Эластичность рынков

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

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

Цена последнего галлона

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

Как только последний галлон, который и так вытек из уже пробуреных скважин, продан, следующий галлон стоит значительно дороже. «Значительно» означает ОЧЕНЬ дороже. Ради него нужно проводить геологическую разведку, бурить новые скважины и т.д. Пока что звучит осмысленно, правда?

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

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

Цена часа программиста

А теперь попробуем приложить те же самые принципы к оплате программиста, как диктуется рынком. Для начала, а как же определяется цена труда? Ответ на данный вопрос был дан еще в девятнадцатом веке Адамом Смитом и Карлом Марксом. Цена труда в определенной индустрии/профессии определяется ценой воспроизовдства трудовых ресурсов. То есть, за человека определенной профессии нужно в среднем, подчеркиваю: в среднем, платить столько, чтобы он был способен содержать себя, иметь детей, вырастить их и дать им образование, чтобы когда он выйдет на пенсию или, что более вероятно в современном мире, умрет, они могли его заменить.

Кстати, у меня одно дите в колледже и второе планирует поступать на следующий год. Я вам скажу честно и уверенно: оплата труда программиста в Америке куда ниже, чем думал Адам Смит. Вот тут-то мы и приходим к «в среднем» (помните, я попросил это запомнить?)

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

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

Кстати, возможно вас возмутило, что я не упомянул Россию наравне с Индией и Китаем. Увы, вопрос не ко мне, а к российским женщинам, которые по данным статистики (например, CIA fact book) не спешат рожать в том же темпе (а значит, так же дешево), что китайки и индийки. Да-да, я знаю, экономика – очень циничная наука. (Вздох...) В любом случае, будь Россия в этой картинке или нет, идея в том, чтобы вывести производство столь дорогого ресурса как профессионалы в более дешевые страны. Сами судите, хорошо это для экономики или нет. IMHO, outsouring production of smart educated people is probably the dumbest thing any nation can do... Извиняюсь за английский, не то чтобы у меня не хватило слов на русском, чтобы выразить эту мысль, но опубликовать эти слова здесь затруднительно по цензурным соображениям.

Цена последнего часа программиста

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

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

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

Затем он остается на десятый час. Теперь его зарплата за каждый – обратите внимание, не за последний, а за каждый час – включает то, что он теперь неспособен сделать – еда теперь доставляется из ресторана, а краны и туалеты чинит специальная служба. Отгадайте, кто за это платит? Ну, да, вроде бы о сам, но в конечном счете фирма, его нанявшая, поскольку это теперь «рыночная цена» программиста.

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

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

По сути мы имеем дело с тем же самым явлением, что и цена последнего галлона нефти. Дайте программистам дышать, и они сами будут стричь свои лужайки и прибирать свои задние дворы. Жмите их дальше, и это будут делать команды неквалифицированных, но многочисленных работников. И вы за это будете платить. Цена восьмого часа программиста непропорционально меньше чем цена девятого или десятого часа. И если вы неспособны контролировать свое общество, чтобы девятый, десятый, одиннадцатый или двенадцатый час не были использованы, то вы будете платить цену двенадцатого часа за все двенадцать часов – от первого до двенадцатого каждый день.

А теперь – я знаю, это буйная фантазия – но попытайтесь представить себя на месте CEO компании, где работает этот потогонный менеджер. Вам нравится идея платить значительно больше за час, чем это необходимо? Это то, что вы делаете. Именно потому, что многие люди считают сверхурочные в нашей индустрии нормой.

Enjoy! Ave!

from: eldar's blog