Один коллега-программист, как-то, задумавшись над задачей, сказал: «нам нужно придумать способ универсального хранения любых взаимосвязей...»
Но это так, вспомнилось при виде словосочетания «весь софт всех уровней...».
А если серьезнее, то действительно обработка ошибок, и как ее делать правильно — серьезный стратегический вопрос во всем конструировании ПО. Я вот для себя до сих пор так единственно правильного универсального решения не нашел. Ну вот есть централизованный способ — единственный обработчик исключений близко к входу программы, и любая ошибка вызывает raise, передающее управление этому обработчику. Но получается неудобно — ведь не каждая нештатная ситуация должна прерывать всю программу — иногда более правильно повторить попытку несколько раз (чтение из сокета TCP — может сетевое соединение к энной попытке отвиснет), а иногда лучше даже просто продолжить исполнение, но написать в лог «фигня какая-то случилась, едем дальше, но хорошо бы разобраться, как будет время, что это было такое». Именно это и происходит на практике, причем на проектах совершенно разного масштаба — от утилит под Windows до довольно больших гетерогенных систем. И тоже получается неудобно — потому что в дереве, которое образуют пути исполнения кода, образуются локальные узлы обработки ошибок (любой try… catch или аналогичная конструкция фактически образуют такой узел), образуются они хаотически, сколько их получится, предсказать невозможно, и до какого размера каждый узел разрастется, тоже заранее непонятно, и вся централизация, о которой иногда мечтают программисты в порыве энтузиазма борьбы с багами («я хочу КАЖДУЮ ошибку писать в ЛОГ») перестает работать — потому что в каждом блоке try… catch мы можем решить, что с этой ошибкой мы справимся, так сказать, «на местном уровне», а наверх, «к федералам», которые хотят «писать в лог», не будем ее передавать. Типа «им там и незачем знать, что у нас тут иногда бывают такие ошибки».
Плюс, возвращаясь к теме, даже в индустрии приняты полярно противоположные подходы — от парадигмы «let it fail», принятой в Erlang и хорошо, вроде бы, работающей в телекоммуникациях до противоположной ей по смыслу «всегда сообщай об ошибках», «никогда не глуши ошибки в секции catch» — а то ты, мол, их никогда в жизни не отловишь, потому что они будут происходить, а ты об этом даже не узнаешь — что, вроде как лучше работает при системном и низкоуровневом прикладном программировании под ОС.
В общем, интересный вопрос, наверное даже фундаментальный.
Тоже у меня Qiwi втихую списали все деньги из «неактивного кошелька». Через неделю после вопроса в службу поддержки, почему они так сделали, получил наконец ответ:
Ну что ж. Формально они имеют вроде бы право так сделать, жаловаться некому, сам прошляпил. А неформально… больше пользоваться никогда не буду, и никому не посоветую.
MDI, dockable toolbars, floating toolbars, skins, ribbons, bloatware
Хм, прямо все это так ясно вспомнилось.
Но удобный (эффективный — не равно «модный») интерфейс все-таки можно сконструировать, и наибольший прогресс в этой области достигнут, наверное, в интерфейсах управления самолетами. Где неудобность (неэффективность) интерфейса реально может стоить жизни и пилоту, и пассажирам.
Это я последнее время размышляю на тему книги Джефа Раскина (пилота и специалиста по интерфейсам, который одно время работал в Apple и оказал некоторое влияние на принятые в этой корпорации принципы интерфейсостроения), и мне тоже кажется, что этот квадратный Metro-Modern-UI — не более чем новая мода, а принципы, следование которым позволяет сконструировать удобный и эффективный, а не просто эффектно выглядящий интерфейс, лежат чуть глубже.
Спасибо за статью, читается на одном дыхании. Конечно, как вы логи снимали… из всех слов, которые приходят на ум по этому поводу, цензурным является только слово «смекалка» :)
Стив Йегге (программист в Google и интересный блоггер, кто не знает) в одной из своих записей проводил идею, что для программиста показателем квалификации является понимание технологии создания компиляторов — лексический анализ, синтаксический анализ, семантический анализ, оптимизация и кодогенерация. Можно считать, что это пять частично пересекающихся «уровней». Но «выше» (условно) по уровням тогда будут находиться вопросы, например, дизайна языков программирования (полезно ли добавить эту фичу? полезно ли убрать другую фичу?), а «ниже» (тоже условно) будут находиться вопросы, относящиеся к хардверной реализации — как скомпоновать функциональные блоки вычислительной машины между собой, как развести плату, вплоть до дизайна самих микросхем и элементов.
В общем, этих «уровней» много, и все, действительно, в ум не помещаются.
Очень похоже на то. Тут же все программисты, которых уже не должен так уже сильно удивлять факт, что на любом Тьюринг-полном языке программирования можно сделать реализацию любого другого Тьюринг-полного языка программирования. А тут что-то очень похожее, но мне непонятно, это «более сильное», «более слабое» или «эквивалентное» утверждение, потому что я совсем не математик. А вот автор, похоже, по характеру мышления именно математик, а эту инженерно-художественную работу выполнил как наглядное доказательство некой теоремы.
Хотя голова от удивления немного кружится, да. Даже не от реализации (я ничего подобного не умею), а именно когда «улавливаешь принцип».
Интересно, да. Спасибо. О «логическом квадрате» и в самом деле раньше не слышал, что нисколько не делает мне чести, но зато заставляет очередной раз испытать удивление, смешанное с некоторым испугом, при виде того, как быстро из нескольких простых и понятных аксиом вырастает необъятное древо теории, в которой следствия все так же следуют из посылок, но чтобы сказать, что они следуют «с очевидностью», надо иметь очень серьезный скилл.
Хм, небольшой рефакторинг: если П1 = KDF (пароль), то можно не вводить термин «симметричный секретный ключ П1», а вместо него везде подставлять термин «пароль». Получится такое же корректное рассуждение, но короче :)
В общем, самое слабое место — пароль, который я, во-первых, знаю, и, который, во-вторых, другие имеют теоретическую возможность тоже узнать, применив ко мне методы социальной инженерии, спектр которых широк — где-то в середине этого спектра находятся трояны и кейлоггеры, а уж что на его границах, каждый может представить себе сам, а лучше даже и не представлять.
Если же с практической стороны, то от того, что сервис выдаст мне плохую версию index.html, которая передаст мой драгоценный пароль открытым текстом куда мне не надо (проблема «недоверенного клиента», вроде так называется?) в принципе теоретически в какой-то мере мог бы защитить институт PKI, аналогичный применяемому сейчас для SSL, только подписывать надо не доменное имя, а хэш хорошего, надежного index.html, который, как подтвердили независимые аудиторы, никуда налево мой драгоценный пароль не передает. Это по сути и делали в Microsoft, когда подписывали свои msi-инсталляторы, но в последнее время они мне не попадаются, что наводит на мысли, что они морально устарели. Боюсь, что вместе с институтом «подписи exe-шников».
— Какие могут быть формальности между друзьями! Вася, сделай мне программу сортировки.
— А что такое сортировка?
— Мне надо, чтобы я вводил любые числа, а программа выдавала УПОРЯДОЧЕННЫЕ числа.
(через неделю)
— Ты что, Вася! Я ввожу 5 4 7 6, а твоя программа выдает 1 2 8 9.
— Так бы и сказал, что она должна использовать ВВЕДЕННЫЕ числа.
(через неделю)
— Ты что, Вася! Я ввожу 5 4 7 6, а она выдает 4 5 6.
— Так бы и сказал, что ВСЕ числа должны присутствовать.
(через неделю)
— Ты что, Вася! Я ввожу 5 4 7 6, а она выдает 4 5 6 7 и 8 и 9.
— Я выдал все, а от себя ДОБАВИЛ, по дружбе, чтобы ты от меня отстал, наконец.
(через неделю)
— Ты что, Вася! Я ввожу 5.4 и 7.6, а она даже два числа отказывается сортировать.
— А откуда я знал, что тебе НЕ ТОЛЬКО целые надо сортировать?
Может тебе завтра взбредет комплексные сортировать?! Последний раз!!!
(через неделю)
— Ты что, Вася! Программа больше девяти чисел не сортирует...
Согласен, когда число открытых файлов доходит, скажем, до 50-ти, табы уже не справляются. Они работают до тех пор, пока все открытые вкладки видны на экране, а это 7-10 файлов (кошелек Миллера). Дальше нужно что-то другое. Я пока использую плагин Buffer Explorer, но мне там сильно не хватает прогрессивного фильтра (когда вводишь сочетание букв, и по мере ввода в списке остаются только строки, содержащие это сочетание). Все никак не соберусь его написать, хотя и хочется.
У меня были мысли, что неплохо бы вставить несколько картинок, но, насколько я знаю, тут для них надо использовать специальный хаброхостинг, а я пока еще не нашел, где он находится.
Языки переключаю системным переключателем (Punto Switcher позволяет повесить переключение раскладки на Caps Lock, чем я и пользуюсь).
Эти две строчки у меня в _vimrc тоже есть, и переключение по Ctrl-^ вполне работает, но через некоторое время я понял, что использовать системный переключатель удобнее. Прочитав книгу Джефа Раскина, я даже понял, почему — так увеличивается «монотонность» (в его терминах) интерфейса. Он называет «монотонным» интерфейс, в котором одно действие можно выполнить только одним способом, и считает эту «монотонность» положительной характеристикой. Мне кажется, он прав — если везде переключать раскладку одним способом (по Caps), а в Vim'е — другим (по Ctrl-^), это будет создавать некоторую путаницу.
Но это так, вспомнилось при виде словосочетания «весь софт всех уровней...».
А если серьезнее, то действительно обработка ошибок, и как ее делать правильно — серьезный стратегический вопрос во всем конструировании ПО. Я вот для себя до сих пор так единственно правильного универсального решения не нашел. Ну вот есть централизованный способ — единственный обработчик исключений близко к входу программы, и любая ошибка вызывает raise, передающее управление этому обработчику. Но получается неудобно — ведь не каждая нештатная ситуация должна прерывать всю программу — иногда более правильно повторить попытку несколько раз (чтение из сокета TCP — может сетевое соединение к энной попытке отвиснет), а иногда лучше даже просто продолжить исполнение, но написать в лог «фигня какая-то случилась, едем дальше, но хорошо бы разобраться, как будет время, что это было такое». Именно это и происходит на практике, причем на проектах совершенно разного масштаба — от утилит под Windows до довольно больших гетерогенных систем. И тоже получается неудобно — потому что в дереве, которое образуют пути исполнения кода, образуются локальные узлы обработки ошибок (любой try… catch или аналогичная конструкция фактически образуют такой узел), образуются они хаотически, сколько их получится, предсказать невозможно, и до какого размера каждый узел разрастется, тоже заранее непонятно, и вся централизация, о которой иногда мечтают программисты в порыве энтузиазма борьбы с багами («я хочу КАЖДУЮ ошибку писать в ЛОГ») перестает работать — потому что в каждом блоке try… catch мы можем решить, что с этой ошибкой мы справимся, так сказать, «на местном уровне», а наверх, «к федералам», которые хотят «писать в лог», не будем ее передавать. Типа «им там и незачем знать, что у нас тут иногда бывают такие ошибки».
Плюс, возвращаясь к теме, даже в индустрии приняты полярно противоположные подходы — от парадигмы «let it fail», принятой в Erlang и хорошо, вроде бы, работающей в телекоммуникациях до противоположной ей по смыслу «всегда сообщай об ошибках», «никогда не глуши ошибки в секции catch» — а то ты, мол, их никогда в жизни не отловишь, потому что они будут происходить, а ты об этом даже не узнаешь — что, вроде как лучше работает при системном и низкоуровневом прикладном программировании под ОС.
В общем, интересный вопрос, наверное даже фундаментальный.
Ну что ж. Формально они имеют вроде бы право так сделать, жаловаться некому, сам прошляпил. А неформально… больше пользоваться никогда не буду, и никому не посоветую.
Хм, прямо все это так ясно вспомнилось.
Но удобный (эффективный — не равно «модный») интерфейс все-таки можно сконструировать, и наибольший прогресс в этой области достигнут, наверное, в интерфейсах управления самолетами. Где неудобность (неэффективность) интерфейса реально может стоить жизни и пилоту, и пассажирам.
Это я последнее время размышляю на тему книги Джефа Раскина (пилота и специалиста по интерфейсам, который одно время работал в Apple и оказал некоторое влияние на принятые в этой корпорации принципы интерфейсостроения), и мне тоже кажется, что этот квадратный Metro-Modern-UI — не более чем новая мода, а принципы, следование которым позволяет сконструировать удобный и эффективный, а не просто эффектно выглядящий интерфейс, лежат чуть глубже.
Стив Йегге (программист в Google и интересный блоггер, кто не знает) в одной из своих записей проводил идею, что для программиста показателем квалификации является понимание технологии создания компиляторов — лексический анализ, синтаксический анализ, семантический анализ, оптимизация и кодогенерация. Можно считать, что это пять частично пересекающихся «уровней». Но «выше» (условно) по уровням тогда будут находиться вопросы, например, дизайна языков программирования (полезно ли добавить эту фичу? полезно ли убрать другую фичу?), а «ниже» (тоже условно) будут находиться вопросы, относящиеся к хардверной реализации — как скомпоновать функциональные блоки вычислительной машины между собой, как развести плату, вплоть до дизайна самих микросхем и элементов.
В общем, этих «уровней» много, и все, действительно, в ум не помещаются.
Хотя голова от удивления немного кружится, да. Даже не от реализации (я ничего подобного не умею), а именно когда «улавливаешь принцип».
В общем, самое слабое место — пароль, который я, во-первых, знаю, и, который, во-вторых, другие имеют теоретическую возможность тоже узнать, применив ко мне методы социальной инженерии, спектр которых широк — где-то в середине этого спектра находятся трояны и кейлоггеры, а уж что на его границах, каждый может представить себе сам, а лучше даже и не представлять.
Если же с практической стороны, то от того, что сервис выдаст мне плохую версию index.html, которая передаст мой драгоценный пароль открытым текстом куда мне не надо (проблема «недоверенного клиента», вроде так называется?) в принципе теоретически в какой-то мере мог бы защитить институт PKI, аналогичный применяемому сейчас для SSL, только подписывать надо не доменное имя, а хэш хорошего, надежного index.html, который, как подтвердили независимые аудиторы, никуда налево мой драгоценный пароль не передает. Это по сути и делали в Microsoft, когда подписывали свои msi-инсталляторы, но в последнее время они мне не попадаются, что наводит на мысли, что они морально устарели. Боюсь, что вместе с институтом «подписи exe-шников».
But there are good parts.
Эти две строчки у меня в _vimrc тоже есть, и переключение по Ctrl-^ вполне работает, но через некоторое время я понял, что использовать системный переключатель удобнее. Прочитав книгу Джефа Раскина, я даже понял, почему — так увеличивается «монотонность» (в его терминах) интерфейса. Он называет «монотонным» интерфейс, в котором одно действие можно выполнить только одним способом, и считает эту «монотонность» положительной характеристикой. Мне кажется, он прав — если везде переключать раскладку одним способом (по Caps), а в Vim'е — другим (по Ctrl-^), это будет создавать некоторую путаницу.