avl

Да... Я конечно догадывался, что в инете можно найти порой очень талантливые произведения, но вот это просто убило наповал! :) Вот уж воистину "мозг человеческий - как это мало" :)

Нужно, чтоб кто-то кого-то любил.
Это наивно, и это не ново.
Не исчезай, петушиное слово.
Нужно, чтоб кто-то кого-то любил.

Нужно, чтоб кто-то кого-то любил:
Толстых, худых, одиноких, недужных,
Робких, больных - обязательно нужно,
Нужно, чтоб кто-то кого-то любил.

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

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

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

Шедевр взят отсюда

(В оригинале - Distinguish Business Exceptions from Technical)

В большинстве случаев есть лишь две причины, из-за которых что-то может пойти не так во время выполнения программы. Это технические проблемы, мешающие работе приложения, и бизнес-логика, не дающая нам использовать приложение неправильно. В большинстве современных языков программирования, таких как LISP, Java, Smalltalk, и C#, для обеих ситуаций используется механизм исключений. Однако эти две ситуации столь различны, что их стоит аккуратно разделять и не смешивать. Если для обеих ситуаций использовать одну и ту же иерархию исключений (не говоря уже о том, чтобы использовать одни и те же классы), то это может стать источником серьезной путаницы.

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

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

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

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

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

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

Автор оригинала - Dan Bergh Johnsson

Перевод мой, при использовании ссылка на мой живой журнал обязательна!

Недавно задумался о том, насколько велика разница в подходах к разработке пользовательского интерфейса у тех, кто пишет свой софт на продажу, не являясь при этом гигантом вроде Адоба или Микрософта, и у остальных :)

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

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

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

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

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

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

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

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