The Daily WTF на русском

Лучший IT подкаст на просторах нашего интернета

IBM только что выпустила офисный пакет с открытыми исходниками под названием IBM Lotus Symphony. Похоже на очередной дистрибутив StarOffice. Но я подозреваю, что они просто хотят вычеркнуть из истории настоящий Lotus Symphony, который в свое время объявили чуть ли не вторым пришествием, а он оказался совершенно никчемным. Это был аналог Джильи из мира программ.

В конце 80-х в Lotus ломали голову, что же делать дальше с их флагманским табличным и графическим продуктом, Lotus 1-2-3. Возникло две очевидных мысли: во-первых они могли добавить функций. Например, встроить текстовый редактор. Получившийся продукт был назван Symphony. Другая мысль, которая тоже казалась очевидной, это создать трехмерный редактор таблиц. Так получился 1-2-3 версии 3.0.

Обе задумки столкнулись с серьезной проблемой – старым ограничением DOS на 640 Кб памяти. IBM уже начала поставлять несколько компьютеров с 80286 чипами, которые могли адресовать больше памяти, но в Lotus решили, что не так много найдется людей, которые готовы потратить на компьютер 10000 $. Поэтому они все ужимали и ужимали. Потратив 18 месяцев на то, чтобы втиснуть 1-2-3 для DOS в 640 Кб, они потеряли уйму времени и, в конце концов, отказались от трехмерности, чтобы таки запихнуть все в память. В случае же Symphony они просто резали все подряд налево и направо.

Ни один из путей не оказался верным. К тому времени как был выпущен 1-2-3 версии 3.0, у всех уже были 80386-е с двумя или четырьмя мегабайтами оперативной памяти. К тому же в Symphony были невнятные таблицы, невнятный текстовый редактор, да и вообще немало было невнятного.

«Это все замечательно, папаша», скажете вы. «Но кого волнуют старые текстовые программы?»

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

Мало памяти и слабые процессоры

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

В конце 90-х некоторые компании, включая Microsoft и Apple, заметили (просто немного раньше, чем все остальные), что закон Мура позволяет не очень сильно переживать из-за производительности и использования памяти... а просто создавать всякие клевые штуки, и ждать пока подоспеет железо. Microsoft выпустила первую версию Excel для Windows в то время, когда 80386-е были слишком дороги, но они набрались терпения. Через пару лет вышел 80386SX и любой, кто мог позволить себе потратиться на клон за 1500$ мог запускать Excel.

Как программист, благодаря копеечным ценам на память и удвоению скорости процессоров каждые два года, вы можете выбирать. Можете потратить шесть месяцев, переписывая внутренние циклы на Ассемблере, или потратить шесть месяцев играя барабанщиком в рок группе, и в обоих случаях ваша программа будет работать быстрее. У программистов на ассемблере нет фанаток.

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

Кроме одного случая: браузерного JavaScript-а работающего в AJAX приложениях. А так как в этом направлении движется практически все программирование, тут есть над чем подумать.

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

Впрочем, история имеет свойство повторяться. Каналы становятся дешевле. Люди придумывают как прекомпилировать JavaScript.

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

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

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

Язык программирования С был изобретен с явной целью - сделать перенос приложений с одного набора команд на другой проще. И он неплохо справился, правда не был 100% переносимым, поэтому мы получили Java, которая была еще более переносимой, чем С. Ммммммм.

Сейчас основная беда переносимости это – тада! - клиентский JavaScript, и особенно DOM в веб браузерах. Написание приложений, которые работают во всех браузерах, это сущий кошмар. Просто нет другого выхода, кроме полного тестирования на Firefox, IE6, IE7, Safari и Opera, и знаете что? У меня нет времени тестировать под Opera. Фигово быть Oper-ой. У начинающих браузеров нет ни единого шанса.

Что же должно произойти? Ну, вы можете умолять Microsoft и Firefox быть более совместимыми. Удачи. Можете пойти по пути p-code/Java и соорудить небольшую песочницу поверх базовой системы. Но песочницы это тормозильницы, они медленные и лажовые, поэтому Java апплеты сдохли, сдохли, сдохли. Создавая песочницу, вы не претендуете больше чем на одну десятую скорости базовой платформы, и никогда не сможете поддерживать все модные функции, которые есть на одной платформе, и нет на других. (Я все еще жду, когда мне покажут Java мидлет для телефона, который умеет работать со всеми функциями телефона, вроде камеры, адресной книги, SMS сообщений или GPS приемником).

Песочницы не работали тогда, не работают они и сейчас.

Что будет дальше? Те, кто посообразительней сделают то же, что уже сработало в Bell Labs в 1978: создадут переносимый и эффективный язык программирования наподобие С. Он будет компилироваться в «родной» код (родным в данном случае будет JavaScript и реализации DOM) с разными кодогенераторами для различных целевых платформ, которые вылизаны одержимыми производительностью фанатами для того, чтобы вам о ней больше не вспоминать. Он будет таким же производительным как обычный JavaScript с единым способом доступа ко всем возможностям, и он будет компилироваться в родной код для IE и родной код для Firefox автоматически и без проблем с переносимостью. Да, он доберется и до вашего CSS и сделает с ним что-то ужасное, каким-нибудь непотребным, но все же корректным способом, поэтому вам больше никогда не придется думать о несовместимости CSS. Никогда. Ах, что это будет за славный день.

Интерактивность и стандарты пользовательских интерфейсов

Мэйнфрейм IBM 360 использовал пользовательский интерфейс под названием CICS, который вы до сих пор можете увидеть в аэропорту, если перегнетесь через стойку регистратуры. Это экран с зелеными символами размером 80 на 24 знакоместа, который, разумеется, работает только в текстовом режиме. Мэйнфрейм отправляет форму «клиенту» (клиент это умный терминал 3270). Терминал умный потому, что он знает, как отобразить форму и позволяет вам вводить данные в форму, не обращаясь к мэйнфрейму вообще. Отчасти поэтому мэйнфреймы были гораздо мощнее, чем Unix, процессору не надо было управлять вашим вводом, за это отвечал умный терминал. (Если вы не могли себе позволить поставить всем умные терминалы, вы покупали миникомпьютер System/1, который подключался между терминалами и мэйнфреймом и управлял вводом).

Как бы то ни было, после того как вы заполнили форму, вы нажимали ОТПРАВИТЬ, и все ваши ответы отправлялись на сервер для обработки. Потом машина присылала другую форму. И так снова и снова.

Уродство. Ну и как вы сделаете в такой системе текстовый редактор? (Вообще-то никак. Для мэйнфреймов никогда не было нормального текстового редактора).

Это был первый этап. Это в точности то же самое, что и эпоха HTML в интернете. HTML это CICS со шрифтами.

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

Во время второго этапа была другая проблема – не было ясных стандартов для пользовательских интерфейсов... у программистов было слишком много свободы, поэтому все всё делали по-разному. Из-за этого зная как пользоваться программой Х, использовать программу Y было не легче. В WordPerfect и Lotus 1-2-3 были совершенно разные системы меню, клавиатурные интерфейсы и структура команд. А о копировании данных между этими приложениями вообще речи не шло.

То же самое сейчас и с AJAX приложениями. Нет, конечно, пользоваться ими гораздо удобнее, чем первыми DOS приложениями, с тех времен мы всё же кое-чему научились. Но AJAX приложения не целостны, и они очень плохо работают друг с другом – вы не можете вырезать и вставлять объекты из одного AJAX приложения в другое, например, я не знаю, как перетащить картинку из Gmail во Flickr. Эй, ребята, копирование и вставка были изобретены четверть века назад.

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

А так как история повторяется, можно ожидать какой-то стандартизации AJAX-овских пользовательских интерфейсов примерно в том же направлении как в свое время было с Microsoft Windows. Кто-то напишет новый SDK, с помощью которого можно будет создавать мощные AJAX приложения с одинаковыми элементами пользовательского интерфейса, которые умеют работать вместе. И чей SDK сумеет завоевать больше умов разработчиков тот и получит такой же бастион в конкурентной борьбе как Microsoft с их Windows API.

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

Представьте себе, например, что вы Google со своим Gmail-ом, и все у вас хорошо. Но затем кто-то о ком вы никогда не слышали, какой-нибудь скажем стартап из Y Combinator, который привлек сумасшедший интерес, продавая NewSDK, сочетающий отличный переносимый язык программирования, компилирующийся в JavaScript, и что еще лучше, огромную AJAX библиотеку, включающую в себя все функции для взаимодействия с другими программами. Не просто копирование и вставка, а мощные сложные функции, вроде синхронизации и единого управления личными делами (поэтому не придется говорить Facebook и Twitter, что вы делаете, можно всё ввести в одном месте). А вы смеетесь над ними, потому что их NewSDK занимает целых 232 мегабайта ... 232 мегабайта JavaScript-а, и чтобы загрузить страницу требуется 76 секунд. Поэтому ваше приложение Gmail не теряет пользователей.

Но потом, пока вы сидите в googleкресле, стоящем в googleplex-е попивая googleчино, и чувствуете себя живее всех живых, выходят новые версии браузеров, которые поддерживают кэшированный скомпилированный JavaScript. И внезапно NewSDK становится невообразимо быстрым. А Пол Грэм дает им еще 6000 пачек доширака, чтобы они остались в деле еще на три года, совершенствуя его.

А ваши программисты распустили нюни, Gmail огромен, мы не можем перенести Gmail на этот дурацкий NewSDK. Нам придется изменить все до единой строчки. Блин, да это же все надо с нуля переписать, вся программная модель перевернута с ног на голову, она рекурсивна и в ней столько скобок, что даже Google не под силу их купить. Последняя строка почти каждой функции состоит из 3296 закрывающих скобок. Чтобы их посчитать придется купить специальный редактор.

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

И пока вы не придаете этому значения, все начинают использовать приложения на NewSDK, и они замечательны, и внезапно партнеры хотят пользоваться только приложениями на NewSDK, а все эти классические чистые AJAX приложения выглядят жалкими поделками, потому что они не умеют копировать и вставлять, синхронизировать, и как следует работать друг с другом. И Gmail становится историей. WordPerfect из мира электронной почты. Вы рассказываете детям, какой у вас был восторг от двухгигабайтного почтового ящика, а они смеются над вами. У них в пилке для ногтей больше двух гигабайт.

Безумная история? Подставьте вместо «Google Gmail» «Lotus 1-2-3». NewSDK будет вторым пришествием Microsoft Windows, именно так Lotus потерял власть над рынком электронных таблиц. И это случится снова, на сей раз в вебе, потому что все факторы и течения в силе. Единственное чего мы пока не знаем, это деталей происходящего, но это случится.

Перевод: Евгений Виговский
Оригинал:http://joelonsoftware.com/items/2007/09/18.html

Дорогие товарищи, рад сообщить, что сегодня состоялось официальное открытие русскоязычной части http:\\worsethanfailure.com, которая находится по адресу http:\\ru.worsethanfailure.com. Теперь все новые посты будут публиковаться там. Этот журнал никуда не денется, но и обновляться скорее всего не будет. Перенастраивайте свои RSS-агрегаторы, готовьте комментарии, приглашайте товарищей по несчастью. Приятного чтения.

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

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

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

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

Это было Windows приложение на VB6, которое использовало для хранения данных SQL Server. В базе данных на SQL Server-е было несколько копий таблиц, в которых были регистрационные данные, какие-то для тестирования, какие-то для поврежденных данных, какие-то для работы. Это было классическое химерное окружение.

В самой важной таблице были сотни столбцов, которые следовали простой и элегантной схеме именования: col001, col002 и так далее. Таким образом, если бы вас когда-нибудь спросили, «Какой столбец между столбцами col174 и col176», то вы бы с легкостью ответили. А если бы вас просили «Что хранится в столбце col175», то вам бы пришлось ответить примерно следующее, «Ну, это зависит от того, что находится в первом столбце. Если там единица, тогда col175 это их рост в дюймах. Если там 'R', значит там находится девичья фамилия матери (если только col023 равно null)». Поверьте, вам обязательно захочется щелкнуть на нижеприведенные снимки:

Вот пример данных из таблицы «MO...04-donotdelete»:

И еще немного:

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

Нил начал переделывать приложение Гаррета с использованием ASP.NET и SQL Server (на этот раз, используя больше одной таблицы). Его начали таскать с проекта на проект, поэтому проект по переделке начал чахнуть. Каждый раз, когда Нил заглядывал в кабинет к своему начальнику, тот или игрался с игрушечным самолетиком, или заказывал на Amazon-е новый смартфон. Из-за нарастающего разочарования Нил ушел.

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

Оригинал:http://worsethanfailure.com/Articles/Med-School-Malpractice.aspx

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

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

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

Нэсс получил у отчаявшегося администратора доступ к серверу резервного копирования и выяснил, по какой именно причине было невозможно восстановить базу. Резервные копии хранились на лентах частями по 2Гб. Ленты для стримера износились, а вышестоящее руководство решило, что платить за новые ленты было неразумно. В конце концов, они только что купили новый сервер с кучей свободного места на дисках. Решили, что будет дешевле нанять студента, который бы загружал ежедневно файлы по FTP.

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

«Так», спросил Нэсс администратора, «а кто-нибудь сказал практиканту, чтобы он вводил 'BIN' перед загрузкой файлов?»

«Нет, а что оно делает?»

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

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

Оригинал:http://worsethanfailure.com/Articles/The-Loony-BIN.aspx