Category: компьютеры

Верхний пост :)

Основной мой вид деятельности на данный момент - разработка ПО в области embedded. Опыт работы - с 2001 года. Сайт-визитка по этой теме: http://avl2.info/.

Кроме этого, есть еще несколько направлений, мне интересных, в которых я в той или иной степени "продвинулся". Никак не связанных с программированием.

1. Естественные роды. Все - на основании собственного (почти :)) опыта рождения двух детей. Я оба раза присутствовал на родах, во второй раз мы вместе с женой составляли план родов, выбирали и общались с акушерками, ходили на курсы подготовки и многое-многое другое :) Опыт вылился в сайт http://ru.naravniporod.com/. Буду рад ответить на вопросы, если кого-то мой опыт заинтересует подробнее.

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

2. Фотография. Началось это увлечение еще с 1996 года, с фотоаппарата "Смена 8М" и черно-белой пленки, проявки ее в бачке и печати фотографий в ванной под увеличителем и красным фонарем. Кое-что из того, что получается сейчас, можно увидеть здесь по тегу "Фото". Коммерческое предложение с ценами и вариантами - на еще одном моем сайте http://www.lepitrenutki.com/, который, правда, на словенском языке - для целевой аудитории.

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

3. Гимнастика для новорожденных. С первым ребенком я открыл для себя динамическую гимнастику. Со вторым - познакомился с абсолютно другим подходом, автором которого является словенка Андрея Семолич, и который она назвала "Педокинетика". (Сайт тоже на словенском). Подход очень и очень интересный, отлично дополняет собой динамическую гимнастику, со вторым ребенком я прошел всю ее методику, начав с 6 недель и закончив моментом, когда малыш начал делать первые шаги. И очень доволен результатом. В мае 2013 года я получил сертификат инструктора "Педокинетики" первого уровня (после двух лет обучения, в том числе более 200 часов практики с реальными детьми и 6-часового экзамена на реальных и непростых группах). Впереди еще минимум три года обучения :) Так что в ближайшее время появится еще одно направление в моей деятельности :) По которому я тоже буду рад помочь тем, кого это заинтересует!

Интуитивно-понятный интерфейс

Всем хороша программа CDEx, кроме одного. После того, как она отконвертировала файлы, надо обладать очень развитой интуицией, чтобы их найти.

Вот как выглядит ее интерфейс, где указывается, куда сохранять результат работы.

Но если вы попробуете зайти в папку C:\Program Files (x86)\CDex\my music\, то с удивлением обнаружите, что таковой папки нет. Совсем нет.

А сохраняет он результат работы вот куда: C:\Users\avl\AppData\Local\VirtualStore\Program Files (x86)\CDex\my music\

Вот блин как?

68. Помещайте все в систему контроля версий

Да, давно я что-то ничего не переводил... Самое страшное для регулярности - это нарушить ее в первый раз :)

Но все же надо закончить серию :) Итак, в оригинале Put Everything Under Version Control

Помещайте все, что относится к вашему проекту, в систему контроля версий. Все, что вам для этого нужно, это:

  • бесплатные инструменты (SVN, Git, Mercurial, СМЫ)
  • достаточное количества места на диске
  • недорогой производительный сервер
  • доступ к сети


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

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


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

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

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

После первого знакомства с красотой работы с системой контроля версий следование нескольким простым правилам еще более повысит эффективность вашей команды:

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

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

Автор оригинала - Diomidis Spinellis

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

66. Предотвращайте ошибки

(В оригинале - Prevent Errors)

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

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

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

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

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

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

Подсказки отличаются от инструкций. Подсказки появляются в момент взаимодействия, инструкции – перед ним. Подсказки предоставляют контекст, инструкции диктуют поведение.

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

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

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

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

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

Автор оригинала - Giles Colborne

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

65. Используйте типы из вашей предметной области

(В оригинале - Prefer Domain-Specific Types to Primitive Types)

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

Этот и множество других примеров ошибок могли бы быть предотвращены, если бы использовался более строгий механизм типов предметной области. Это также объясняет множество свойств языка Ада, одной из основных целей разработки которого была реализация встраиваемых систем высокой надежности (safety-critical). Язык Ада использует строгую типизацию с проверкой на этапе компиляции как встроенных типов, так и типов, определенных пользователем.


type Velocity_In_Knots is new Float range 0.0 .. 500.00;
type Distance_In_Nautical_Miles is new Float range 0.0 .. 3000.00;

Velocity: Velocity_In_Knots;
Distance: Distance_In_Nautical_Miles;
Some_Number: Float;

Some_Number:= Distance + Velocity; -- В этом месте компилятор выдаст ошибку типизации.

Разработка приложений в менее критичных областях тоже может воспользоваться этим преимуществом определяемых типов вместо использования встроенных вроде string или float. В Java, C++, Python и других языках абстрактный тип – это класс. Использование классов вроде Velocity_In_Knots и Distance_In_Nautical_Miles значительно повышает качество кода:

  • код становится более читаемым, поскольку явно указываются значения из предметной области в отличие от «общих» типов Float или String;
  • код становится более тестируемым;
  • код способствует повторному использованию.

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

Мораль – используйте типы из предметной области с целью разработки качественного программного обеспечения.

Автор оригинала - Einar Landre

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

49. Изучайте иностранные языки!

(В оригинале - Learn Foreign Languages)

Программистам приходится общаться. Много общаться.

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

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

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

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

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

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

Автор оригинала - Klaus Marquardt

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

Простая авторизация, или как про#рать много денег :)

Сегодня отдохнем от "97 вещей", вместо этого будет другой перевод :)

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

Очередная статья на WorseThanFailure, как мне кажется, отлично иллюстрирует это различие. Оригинал статьи тут , а чуть ниже - мой ее перевод.

«Это невозможно!» - сказал Геральд тоном, не терпящим возражений. – «Просто невозможно!»

«Так, давай проясним ситуацию» - ответил Крейг. – «Под 'Невозможно' ты ведь понимаешь 'Слишком проблематично', однако же ты классный спец, чтобы это сделать, ведь так?». Это вызвало несколько улыбок у остальных коллег, слушающих этот диалог, однако Геральд только вздохнул: «Нет, Крейг, под 'Невозможно' я понимаю именно 'Невозможно'. Невыполнимо. Неосуществимо в принципе. Если конечно кто-нибудь не изменит то, как сейчас организована коммуникация через Интернет».

«Но ведь нам не надо менять это для всех!» - увидев надежду, оживился Крейг. – «Всего лишь один клиент! У тебя получится!»

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

И в результате именно Геральду было поручено разработать недостающую функциональность: систему аутентификации на основе IP, не требующую ввода логина-пароля.

Основным возражением Геральда было то, что большинство пользователей (а у данного клиента это были вообще все пользователи) находились за роутером. Т.е. у каждого клиента был свой внутренний IP, а снаружи они все были видны под единственным внешним, что делало невозможным отличить пользователей друг от друга.

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

В виду невозможности получить IP пользователя снаружи, Геральд предложил использовать cookies. Если бы пользователь один раз прошел авторизацию, то у него бы сохранилось авторизационное cookie на неопределенное время. Понятно, что очистка cookies бы привела к необходимости повторить авторизацию, но это казалось незначительным по сравнению с простотой реализации. Однако клиент считал иначе – его пользователи не должны были запоминать еще один логин, даже если вводить его надо было бы лишь один раз.

Геральд предложил идею настроить на прокси сервере клиента поддержку специального HTTP заголовка, в котором и передавать IP, но эта идея тоже была отвергнута – злоумышленник мог бы легко подделать HTTP заголовок и тем самым взломать систему.

Третьей идеей Геральда стало использование соединения VPN. Сервер приложений мог бы установить соединение с клиентом внутри сети, что бы позволило использовать Windows-аутентификацию. Это была его лучшая идея, делающая вещи еще более простыми – теперь достаточно было лишь списка пользователей, имеющих доступ, вместо списка их IP. К сожалению, администраторы сети клиента категорически отвергли это, мотивируя тем, что «VPN соединения ужасно небезопасны».

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

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

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

И вот от менеджера проекта клиента пришло письмо: «Геральд! Добавь пожалуйста следующий IP адрес в список разрешенных: 10.1.23.97».

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

46. Изучите ограничения

(В оригинале - Know Your Limits)

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

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

Сложность определяется функцией O(f(n)), являющейся для n, равного размеру входных данных, приближенным значением требуемого объема памяти или времени по мере приближения n к бесконечности. Важные классы сложности включают ln(n), n, n ln(n), ne, and en

Графическое представление наглядно показывает, что по мере роста n O(ln(n)) значительно меньше, чем O(n) и O(n ln(n)), а n в свою очередь значительно меньше O(ne) и O(en). Для доступных значений n можно выделить три класса сложности – константная, линейная и бесконечная.

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

Структура Время доступа Объем
register < 1 ns 64 b
cache line 64 B
L1 cache 1 ns 64 KB
L2 cache 4 ns 8 MB
RAM 20 ns 32 GB
disk 10 ms 10 TB
LAN 20 ms > 1 PB
Internet 100 ms > 1 ZB


Заметьте, что объемы и быстродействие отличаются на несколько порядков. Кэширование используется практически на всех уровнях, чтобы скрыть эти различия, однако оно работает лишь для предсказуемого доступа. При частых «промахах кэша» система может замедлиться в разы. Например, чтобы в случайном порядке прочитать все байты жесткого диска, может понадобиться 32 года. А чтобы случайно просмотреть всю оперативную память – 11 минут. Случайный доступ непредсказуем. Исходя из этого, следует помнить, что повторный доступ к уже использовавшимся элементам и последовательный доступ практически всегда работают эффективно.

Алгоритмы и структуры данных значительно отличаются по эффективности использования кэша. Например:
Линейный поиск выполняет последовательный перебор, но требует O(n) сравнений
Бинарный поиск в отсортированном массиве требует лишь O(log(n)) сравнений
Поиск по дереву van Emde Boas также требует O(log(n)) сравнений и при этом эффективно использует кэш (cache-oblivious)

Размер массива Время поиска (ns)
8 50 90 40
64 180 150 70
512 1200 230 100
4096 17000 320 160
Алгоритмlinear binary vEB


И как же сделать выбор? Измеряя. В таблице показано время, требуемое для поиска 64-битного целого числа тремя методами в массивах различного размера. На моем компьютере линейный поиск наиболее выгоден для небольших массивов, однако существенно проигрывает при увеличении размера. Алгоритм van Emde Boas выигрывает всегда благодаря предсказуемому доступу к данным.

Автор оригинала - Greg Colvin

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

40. Установи меня

(В оригинале - Install Me)

Я не просто зашел поинтересоваться вашей программой.

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

Если исследования о работе зрительной системы не врут, то я уже прочитал заголовок и ищу синие подчеркнутые слова «Скачать прямо сейчас». Да, кстати, если я пользуюсь Линуксовым браузером и у меня IP из Великобритании, то скорее всего мне понадобится версия под Линукс с европейского зеркала. И не надо меня об этом спрашивать. Предполагая, что после клика сразу же появится окно загрузки, я указываю, куда сохранить файл и продолжаю чтение.

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

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

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

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

Если ваше ПО – это библиотека, то я продолжу изучать ваш сайт в поисках инструкции о быстром старте. Я хочу также аналог “Hello world” из пяти строчек и без лишнего мозготраха и с подробным описанием того, что должно получиться, если его запустить. Никаких огромных XML файлов или шаблонов, а всего лишь маленький скрипт. И да, конечно же я уже загрузил себе фреймворк вашего конкурента, того самого, который на всех форумах пишет, что его приложение на порядок лучше вашего. И если до сих пор все работает, тогда я загляну в tutorial.

Упс, а что, у вас нет tutorial-a? На том языке, который я понимаю?

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

Я все еще вас не убедил?

Автор оригинала - Marcus Baker

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

О бесплатном ПО и альтернативе фотошопу

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

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

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

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

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

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

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

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

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

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

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

И вдруг вспомнил, что недавно писал о другой программе, AutoHotKey, которая как раз и занимается автоматизацией!

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

Упс, на второй фотке Lightbox благополучно валится с предложением отправить отчет в микрософт... Повтор сценария вручную подтверждает наличие в нем такого бага... Что же, бесплатный софт есть бесплатный софт. Интересно, есть ли этот глюк в платной версии?

Ладно, дописываем в начало цикла старт Lightbox-a, а в конец - его закрытие. И вуаля - все работает! Можно запускать автообработку и идти заниматься своими делами - единственный минус такого решения - невозможность использовать комп во время работы скрипта, поскольку он эмулирует движения мышью, клики и нажатия клавиш на клавиатуре.

Так что а)если поискать, можно найти бесплатный (или как минимум недорогой) аналог почти чего угодно и б)используя две программы в паре, можно получить сильно больше, чем дает каждая из них :)

Осталось найти аналог фотошоп LAB (хотя и нужен он гораздо реже)...