The Daily WTF: Русский Вариант

Эргономика - наше все

Evgeniy Vigovskiy — Mon, 30 Mar 2009 04:15:00 GMT

Какие только чудовища не водятся в дебрях автоматизации бухгалтерского учета. Оцените красоту экземпляра с которым однажды столкнулся Артур. Cвоими впечатлениями он поделился в письме:

Недавно мне поручили соорудить бухгалтерам из нашей компании какую-нибудь программу для подсчета затрат, которые использовали для этого Excel и справочники толщиной в три сантиметра, обновлявшиеся ежемесячно (кстати на самом деле им требовалось 20 копий этих справочников отксеренных вручную!). Попытавшись разобраться я выяснил, что компания уже прикупила для этих целей программу, но никто не смог ей пользоваться. Поэтому, я решил поставить ее и посмотреть, что с ней не так. Потратив пару часов на установку этого чудесного шедевра программирования, мне, наконец, удалось ее запустить. Как оказалось, это старинная программа на Visual FoxPro, которая была создана на базе еще более древней программы на FoxPro работавшей еще под DOS. Новости были так себе, но тем не менее, это не объясняло, почему никто не смог ей пользоваться. Потратив еще два часа, пытаясь понять, что вообще может делать эта чертова программа, я все понял. Только взгляните на этот образец разработки графических интерфейсов.

Error'd: Свобода, равенство

Evgeniy Vigovskiy — Sun, 29 Mar 2009 00:00:00 GMT

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

end_request: I/O error, dev 03:00 (hda), sector 393744
end_request: I/O error, dev 03:00 (hda), sector 213510
EXT3-fs error (device ide0(3,8)): ext3_readdir: diretory #26729 contains a nole
 at offset 0

Саммит директоров

Alex Papadimoulis — Sat, 28 Mar 2009 23:45:00 GMT

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

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

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

День первый.

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

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

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

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

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

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

Позже в тот же день.

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

"Я думаю, проектор заснул" - сказал он - "Может ли кто-то из вас передёрнуть ему питание?"

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

"Вам следует нажать Fn+F4" - предложил кто-то. Докладчик громко клацнул клавишами.

"Вот ёлки", - вздохнул он. "Может надо было Fn+F5 или Ctrl+F5?" Он потыкался в клавиатуру с другими комбинациями клавиш и изрёк несколько цветастых словечек, однако "кина" по-прежнему не было. Пришло время снова позвать электрика.

Через пару минут тот пришёл и оценил обстановку. Затем он взял видеокабель и воткнул его обратно в ноутбук. Проектор снова вернулся к жизни.

Запертые.

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

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

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

"Да мы тут целый день сидели", - ответил один из директоров, - "наверное, телефон сломался".

"Нуу,.." - призадумался администратор, - "вы же мне сейчас по нему звоните, верно?"

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

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

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

Темнота.

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

"Позвольте-ка, я попробую" - сказал один из директоров. И он попробовал сам поклацать выключателем несколько раз. Затем директор покрутил выключатели кондиционеров и розеток. Безрезультатно.

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

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

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

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

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

Оригинал: http://thedailywtf.com/Articles/The-Executive-Summit.aspx
Перевод: 21csm

CodeSOD: Вопрос владения кодом или маразм?

Alex Papadimoulis — Sat, 28 Mar 2009 04:15:00 GMT

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

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

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

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

int    Utilities_CompareDouble(double P, double Q)
{
    _asm
    {
        fld P
        fld Q
        FCOMIP   ST, ST(1)   ;23
        fstp Q
        jc LESS
        and ah,20h
        Jnz EQUAL
        mov eax,0C00002h ;Greater
        jmp EXIT
EQUAL:
        mov eax,0C00001h
        jmp EXIT 
LESS:
        mov eax,0C00003h
EXIT:
    }
}

Jay продолжает: "Неужели же этот парень пытается переписать абсолютно всё? Ведь вот, что было изначально закоммичено в репозиторий":

int StringUtil_Compare(const char *left, const char *right)
{
    int result = 0;

    if(!strcmp(left,right))
        result = 1;

    return result;
}

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

Оригинал: http://thedailywtf.com/Articles/Code-Ownership-Gone-Awry.aspx
Перевод: 21csm
Автор перевода выражает особую благодарность Дмитрию Гриценко за помощь в адаптации труднопереводимых фрагментов публикации.

Error'd: Опасная ошибка

Alex Papadimoulis — Fri, 27 Mar 2009 22:00:00 GMT

"Я увидел это сообщение на одном из терминалов Air Canada, расположенных сзади сидений," - пишет Adrian Petrescu, - "как приятно прочитать такое пролетая в 11,000 футах над землёй."

"Предупреждение: Произошла опасная ошибка при отображении."

"Думаю, это полезно знать," - пишет Ron.

"SGE1188: Такой пароль уже используется другим пользователем. Всё равно хотите его использовать?"

"Терпеливо высидев 45 минут в ожидании врача," - пишет Mike R., "я сдался и купил мобильную версию Texas Hold'em покера. Для своих $7.49 это вполне приличный способ убить время, если закрыть глаза на некоторые ошибки в логике, выползающие время от времени."

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

"Пожалуйста, выберите предпочитаемый язык:
- язык 1
- язык 2

"Ммм," - пишет Dave - "я, пожалуй, возьму.... ээээ... Athlon 64!"

Оригинал: http://thedailywtf.com/Articles/A-Nasty-Error.aspx
Перевод: 21csm

Сын ITAPPMONROBOT-a

Alex Papadimoulis — Wed, 18 Mar 2009 15:30:00 GMT

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

Поэтому мне особенно приятно видеть, что одна статья – ITAPPMONROBOT - воодушевила других ИТ профессионалов на создание своего собственного «робота». И не один раз (смотрим: Сезам откройся), а теперь уже дважды. Феликс объясняет...

У нас в офисе имеется фирменный беспроводной канал, который соединяет нашу сеть со специализированным оборудованием. Сам этот канал, представляет собой обычный компьютер, в который воткнута до идиотизма дорогая PCI-карта с не менее идиотскими драйверами. Примерно раз в пару дней (а иногда и по несколько раз в день), беспроводная карта сходит с ума, и в соответствии с рекомендациями производителя чтобы привести ее в чувство мы «должны просто обесточить компьютер, а потом включить его снова». Фича такая я полагаю.

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

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

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

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

Оригинал: http://thedailywtf.com/Articles/The-Son-of-ITAPPMONROBOT.aspx
Перевод: Евгений Виговский

Сезам откройся

Alex Papadimoulis — Tue, 17 Mar 2009 10:00:00 GMT

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

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

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

На следующее утро, в восемь часов, один из сослуживцев Эммануэля позвонил ему и попросил открыть дверь. Эммануэль отставил свою чашку с кофе, поднялся к своему компьютеру и затем:
1) За-VPN-ился в офис
2) Зашел через SSH на машину в прихожей
3) Запустил ~# eject /dev/scd0

И, щелк, дверь открыта.

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

Оригинал: http://thedailywtf.com/Articles/Open-Sesame.aspx
Перевод: Евгений Виговский

CodeSOD: Наступил Апокалипсис?!

Alex Papadimoulis — Fri, 06 Mar 2009 11:15:00 GMT

На днях Jörg S наткнулся на довольно интересное сообщение о проблеме:

___ Наступил Апокалипсис?! ___
 Ticket ID   : 76831
 Создано : Cary L----------
 Назначено на : Jörg S-----
 Приоритет    : Низкий

   Юридический отдел хочет убедиться, что в нашем релизе 2010 Q1 будет 
   представлен определённый язык, но когда я пытаюсь добавить это в ComplianceTraq,
   то всё время получаю вот что:
   
       ОШИБКА: Пожалуйста, убедитесь, что системные часы настроены верно. И если
       это так... тогда Боже, помоги нам всем, потому что скорее всего из-за багов в
       "Соответствии требованиям" наступил апокалипсис, а мы всё ещё пытаемся их 
       исправить. Будь проклято "Соответствие требованиям"!

   Понимаю, что сейчас у всех нелёгкие времена, но неужели ComplianceTraq знает
   что-то, что не известно мне? Я же не пропустила апокалипсис, верно?!?!

Оглянувшись вокруг и удостоверившись, что на улице не проливается дождём с небес огонь и сера, Jörg S почувствовал уверенность - никакого апокалипсиса и в самом деле не случилось. Тем не менее, он задумался: не эти ли "трагические последствия" подразумевал юридический отдел, расписывая, что будет, если не добиться соответствия требованиям.

Это сообщение исходило от ComplianceTraq - одного из старейших внутрикорпоративных веб-приложений. Его использовали для улаживания всех проблем, которые касались соответствия требованиям к их программным продуктам. Jörg S'у не составило особого труда отыскать сообщение в системе, так как всего один файл содержал в себе слово "апокалипсис".

Else If implementationDate > DateSerial( 2010, 01, 01) Then
    ' Этого не может произойти, т.к. implementationDate не может
    ' быть больше чем следующий год после системной даты... и потому что
    ' очевидно, десятилетия вполне достаточно, чтобы устранить 
    ' даже самые затянувшиеся проблемы с соответствием требованиям

    Response.Write _
        "<B>ОШИБКА</B>: Пожалуйста, убедитесь, что системные часы настроены верно. И " & _
	"если это так... тогда Боже, помоги нам всем, потому что скорее всего из-за багов " & _
	"в ``Соответствии требованиям`` наступил апокалипсис, а мы всё ещё пытаемся " & _
	"их исправить. Будь проклято ``Соответствие требованиям``!"
    Response.End

Очевидно, решение проблемы было делом пяти секунд, но Jörg S не мог не поразиться, почему же девелопер выбрал 01.01.2010 в качестве дня страшного суда. Код казался древним, но ведь любой разработчик должен был осознавать, что неурядицы с соответствием требованиям будут постоянно всплывать то тут, то там. После коммита своих изменений в репозиторий, он бегло просмотрел историю версий файла.

#    User       Checked-in         Comments
----------------------------------------------------------------
1    jorgs      1997-01-10         новый файл
2    jorgs      1997-01-23         исправлены баги
3    jorgs      1998-02-09         добавлены поля для категорий
4    alany      1998-11-26         увеличена длина для названия
 --- snip ---
11   cyrusm     2000-03-13         заменить "Y2K" на "Compliance"
 --- snip ---
33   jorgs      2009-02-09         апокалипсис остановлен

И тут его осенило. В прошлом, когда Jörg S был ещё практикантом, он написал простое веб-приложеньице для слежения за проблемой 2000 года. Спустя годы эта система, должно быть, трансформировалась в ComplianceTraq. И, очевидно, тогда ещё он не познал того, что "невероятный" код запускается слишком часто.

Оригинал: http://thedailywtf.com/Articles/The-Apocalypse-Must-Have-Occured!.aspx
Перевод: 21csm

Alex's Soapbox: Программирование - отстой! Или что-то вроде того.

Alex Papadimoulis — Thu, 05 Mar 2009 21:15:00 GMT

Программирование — это не забава. Это нудное и скучное занятие, и, уж конечно, никакой не подвиг. Чего бы вы там с ним не делали, программирование совершенно точно не будет «секси».

Я знаю, что вы думаете. Всех, кто так говорит — и уж тем более пишет такое в блогах — нужно немедленно лишить их программерской лицензии, отобрать у них клавиатуры и навечно посадить за микроЭВМ с CP/M, 8"-ми дискетами и модемом на 1200 бод.

Безусловно, многим из нас, включая меня, нравится писать код. Но должно ли нам это нравиться?

Почему мы пишем код?

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

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

Хотя порой грань между «скучным» и «секси» софтом может размываться, «секси-программы» представляют собой то, чем мы с вами пользуемся регулярно, каждый божий день: SVN, Google Maps, Visual Studio, Firefox и т.п. По сути, нам как программерам редко приходится пользоваться каким-то нудным ПО.

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

Основы унылого ПО

Для определения скучного ПО есть специальный термин — «информационные системы». И хотя назначение информационных систем варьируется от компании к компании, равно как и конкретные требования, по большому счёту все они одинаковые. В них есть база данных, которая моделирует реальный мир, правила, определяющие то, как данные могут изменяться, интерфейс для работы с базой и уйма различных отчётов.

Формальный процесс создания этих информационных систем впервые появился ещё в 60-х годах, а с 70-х вообще практически не поменялся (Современный Структурный Анализ на диво всё ещё современен). В сущности, вы анализируете проблему, составляете карту потоков данных, структурируете эти потоки, создаёте базу и пишете программы, которые являются интерфейсом для работы с БД.

Мы перешли от «тонких клиентов» в «зеленоглазых» терминалах к «толстым клиентам» в виде приложений для ПК. Затем мы переметнулись к «тонким клиентам» на вебе, а с платформами наподобие Windows Presentation Foundation и глазом моргнуть не успеем, как снова окажемся рядом с «толстыми клиентами». Как бы там ни было, наши системы продолжают делать одно и то же: запись/чтение данных.

Разработка информационных систем особо не поменялась. Не важно, используете ли вы Visual Basic 3.0 или xHTML, принципы остались практически теми же: база данных должна быть представлена взору пользователя в максимально приятном и дружественном свете. Код, который для этого необходим (и всегда был необходимым), довольно уныл:

txtFirstName.DisplayWidth = 30;
txtFirstName.MaxCharLength = 50;
SetTextBoxValidator(txtFirstName, Validations.LettersOnly);
txtFirstName.Enabled = securityContext.CanEdit;
txtFirstName.Value = customerRecord.FirstName;

Эти пять строчек кода, просто устанавливают некоторые свойства UI. Повторите это для каждого поля, каждой сущности, а затем умножьте ещё на 1,5, просто потому, что некоторые поля должны быть доступны из двух разных мест. А теперь добавьте весь код, необходимый для валидации и сохранения данных, полученных из UI. Если математика меня не подводит, в результате мы получаем туеву хучу унылого, скучного кода.

Дилемма разработчика

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

Здесь-то и кроется загвоздка. Как выразился Майкл А. Джексон в своих «Принципах проектирования программ» 1975 года, «Программисты… часто находят спасение в их, в общем-то, понятном, но на деле губительном стремлении к усложнениям и ухищрениям в своей работе. Отстранённые от создания чего-либо большего, чем просто программа, они отвечают тем, что делают эту программу до такой степени замысловатой, чтобы она была достойным вызовом для их профессиональных навыков».

Это наблюдение 35-летней давности изо дня в день находит свои подтверждения здесь, на «The Daily WTF». Самый изощрённый код и истории, опубликованные тут, порождены тягой разработчика к достижению мастерства. Эти стремления никоим образом не являются неким заблуждением или результатом злого умысла, они инстинктивны.

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

private void attachSupplementalDocuments()
{
  if (stateCode == "AZ" || stateCode == "TX") {
    //SR008-04X/I are always required in these states
    attachDocument("SR008-04X");
    attachDocument("SR008-04XI");
  }

  if (ledgerAmnt >= 500000) {
    //Ledger of 500K or more requires AUTHLDG-1A
    attachDocument("AUTHLDG-1A");
  }

  if (coInsuredCount >= 5  && orgStatusCode != "CORP") {
    //Non-CORP orgs with 5 or more co-ins require AUTHCNS-1A
    attachDocument("AUTHCNS-1A");
  }
}

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

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

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

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

Просто примите это

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

Каким бы унылым это не казалось, наша работа состоит исключительно в том, чтобы принести прибыль работодателю, а не удовлетворение нам. Вот, что означает быть профессионалом.

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

Переосмысление разработки ПО

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

Всё, начиная от платформы ("А давайте попробуем Руби!"), включая архитектуру ("да тут не может быть только два уровня") и заканчивая техниками, которые непосредственно используются в коде ("нам нужен аспектно-ориентированный фреймворк!") могут быть — а часто так и есть — продиктованы больше желанием изучить новую технологию, нежели реальными нуждами бизнеса. Выберите неверную платформу или изобретите ошибочную технику, и проект неизбежно обречён.

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

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

2. Служите интересам бизнеса. Каждый ремесленник хочет использовать самые последние, великолепные и мощные инструменты, но они редко необходимы для работы. Подобно этому практически никогда невозможно мгновенно обновить платформы/библиотеки/языки. Тот код 10-летней давности, написанный на «классическом ASP», не устарел — его просто не так прикольно сопровождать.

3. Учитесь вне работы. Саморазвитие — это главный принцип любой профессии, но заниматься этим следует «вне работы», то есть не во время разработки информационных систем. Вместо этого учитесь, создавая приложения для себя, вашей команды, или даже для каких-то open source проектов. Пояснение: «Вне работы» не означает, что вы вообще не должны учиться в процессе работы. Обучение важно, но не занимайтесь им в процессе разработки информационных систем для заказчика. Приберегите это для ваших собственных или внутрикомандных проектов.

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

5. От скуки не уйти. Никакие O/R-мапперы или генераторы кода не смогут избавить вас от факта, что записи, поля, валидаторы и т.п. должны быть прописаны вручную, по крайней мере, в двух местах (фронт-энд и бэк-энд). И UI, генерируемая из базы — это также плохо, как база, генерируемая из UI.

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

... и, если ничто не помогает, ...

7. Найдите себе другую работу. Возможно, вы достигли своего максимума на этой работе. Или может вас просто тошнит от такого типа программирования. Как бы там ни было, существует целая масса программерских возможностей, которые не включают в себя скуку и информационные системы. Конечно, конкуренция будет намного выше, поскольку шедевры наподобие «The Brilliant Paula's bean» рождаются только в недрах IT-корпораций.

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

Оригинал: http://thedailywtf.com/Articles/Programming-Sucks!-Or-At-Least,-It-Ought-To-.aspx
Перевод: 21csm (http://21csm.com)

Error'd: Кина не будет, видеоспама тоже

Evgeniy Vigovskiy — Mon, 05 May 2008 18:30:00 GMT

Проходя мимо кинотеатра, наш читатель Руслан понял, что кина не будет. И кинщик тут был ни при чем.

И хотя "пленки" в камере уже не осталось, ему удалось уговорить ее сделать еще один снимок.

Без чувства меры

Jake Vinson — Mon, 14 Apr 2008 17:45:00 GMT

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

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

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

E10K был огромным, во всех смыслах этого слова: минимум четыре процессора (с возможностью установить 64), живущих в гигантском корпусе 1.7x0.9x1.2 метра, весом 800 кг. Из-за ожидаемого наплыва пользователей сервер должен работать в полную силу - на все шестьдесят четыре процессора. Возможно, это более мощное решение, чем требуется, но, по крайней мере, оно на некоторое время избавит от забот об апгрейде. Хотя, после того, как сайт откроется, взрыв популярности наверняка приведет столько пользователей, что подобная мощь окажется востребованной.

Но это еще не все. В системе существовало три класса пользователей - зарегистрированные, незарегистрированные и персонал. Sun рекомендовала выделить по одному E10K для каждого класса пользователей.

Один E10K в предлагаемой конфигурации стоит около $2,000,000. Так что в сумме выходит шесть миллионов долларов. Разумеется, требуется резервное оборудование, так что удвойте сумму. Шесть серверов, двенадцать миллионов долларов, больше пяти тонн железа.

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

Если вы следили внимательно, мы насчитали до 18 серверов. Железо стоимостью тридцать шесть миллионов долларов. Когда Sun огласил общую стоимость серверов, некоторого дополнительного железа и собственный гонорар, сумма увеличилась до $40,000,000.

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

Сто шесть человек.

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

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

Перевод: miroff в соавторстве c Валерием Скурихиным
Оригинал:http://thedailywtf.com/Articles/Out-of-Balance.aspx

Проклятая дверь

Jake Vinson — Mon, 24 Mar 2008 21:30:00 GMT

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

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

В действительности, лишь несколько вещей омрачали его радость – кофе был хреновый, поскольку в кофейном автомате не было любимого сорта, да двери с электронными замками открывались медленно. Джерми практически не замечал этого, пока однажды опаздывая на совещание, не обратил внимания на то, что ждет 10, 20, 30 секунд после того как провел своей карточкой прежде чем дверь откроется. Волнение улетучилось, после того как другой коллега опоздал еще больше, жалуясь, что «проклятая дверь открывалась, чуть ли не минуту!».

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

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

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

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

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

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

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

Джерми глубоко вздохнул и переименовал accesslog.txt в accesslog2.txt. Сразу же щелканье дверных замков слилось в непрерывный гул и донеслось эхом со всего этажа. Джерми прикусил губу и подошел к ближайшему считывателю. Он провел карточкой, и дверь сразу же открылась. Его решение работало! На следующее утро возле кулера шумели те, кто заметил улучшение, и обсуждали, кто мог быть тем неизвестным героем, починившим двери. Другие не были уверены, в том, что знают, что произошло, он одно они знали наверняка: что-то в мире исправилось этим утром.

Оригинал:http://thedailywtf.com/Articles/The-Haunted-Door.aspx

Mandatory Fun Day: 1.12: Предатель!

George E McDougall — Mon, 03 Mar 2008 09:00:00 GMT

Mandatory Fun Day: 1.11: Попалился

George E McDougall — Sun, 02 Mar 2008 21:00:00 GMT

CodeSOD: SQL Предложения

Alex Papadimoulis — Sun, 02 Mar 2008 17:30:00 GMT

Руководство компании Дэвида не очень доверяло традиционной производственной последовательности отправить/пересобрать/развернуть. По их ощущениям, для этого требовалось слишком много шагов, и прорва времени. Организации требовалось внедрять изменения — в частности исправления ошибок — гораздо быстрее. Поэтому для решения проблемы они внимательно изучили процесс разработки, и аккуратно внесли в него необходимые изменения. Шучу. На самом деле они решили внедрить инновационную методику - «SQL Предложения».

Начальники пришли к выводу, что, так как большая часть их приложения манипулировала данными в базе данных, то большинство багов возникает в результате неправильных SQL запросов. Скорее всего, там было что-то вроде использования LEFT JOIN вместо INNER JOIN, или > вместо >=. Они решили, что раз уж в их приложении уже была база данных, — вы уже поняли к чему все идет — почему бы тогда не хранить все SQL запросы в этой базе данных?

Реализовать задумку поручили ведущему разработчику, который работал денно и нощно, чтобы в результате преобразовать ее в нечто чудовищное: библиотеку «SQL Предложения».

все SQL запросы до единого должны были храниться в таблице sql_sentences
чтобы не хардкодить назначение SQL запроса в его идентификаторе, каждому SQL предложению назначался четырехзначный шестнадцатиричный идентификатор - 0x00F9, 0xA004, и т.д. - вместо GET_ALL_CUSTOMERS
каждому предложению назначались привилегии, метод GetSQLSentence() выполнял несколько других запросов, чтобы убедиться в том, что пользователь имеет право выполнять запрос
дабы ублажить тех разработчиков, которые выступали против хранения SQL запросов в базе, была добавлена конфигурационная переменная “UseHardcodedSQL”

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

string sql;
// @SQLSentence=0x02f0
if ((bool)(Configuration.GetValue("UseHardcodedSQL")))
{
    sql = "SELECT cust_name, cust_phone, cust_addr " +
          "  FROM customers WHERE cust_type='Active'";
}
else
{
    sql = DataConnector.GetSQLSentence(0x02f0);
}

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

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

«Ага», ответил он, «но я еще слышал, что их чертовски трудно сопровождать».

Оригинал:http://thedailywtf.com/Articles/SQL-Sentences.aspx
Перевод:Евгений Виговский