Qt Api Design Principles

Not long ago I have came across the article on Qt API design principles.

There you can find good suggestions on how you should write good API, some ideas on naming convention, designing interfaces. The ideas are quite common, but it is still good to read them once again in good text.

Same article in russian.

Читать дальше......

Bash & debugging

One more thing I've came across in linux is debugging.

Had to implement an application that is separate in two modules: exe and dll. Ok, build scripts put both of those to one directory, but if you just start exe, then linux will not find corresponding dll.


Spent for about a day or two before found a following (and currently the best) solution for myself.

/lib/ld-linux.so.2 --library-path [path_to_library] [executable_name]

Works pretty nice.

Other issue was to get error stream output. Found a bit easier: somewhere in wiki.

[exec_name] 2>&1

This moves error stream to output stream. Quite handy thing for debugging.

Читать дальше......

Все мы в психбольнице

Наткнулся я тут недавно на замечательную книжку Алана Купера "Психбольница в руках пациентов" (Alan Cooper "The Inmates Are Running the Asylum"). Произведение, которое все время чтения выбивает из колеи.

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


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

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

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

Итак, к чему мы пришли. Почитай обругали программеров на чем свет стоит. Вообще, это не плохо -- это так есть. Кто-то вспомнит "Так при чем же тут проектирование интерфейсов?". Вот тут уже можно о сути.

Программирование -- молодая индустрия, в которой очень долгое время программисты сами проектировали взаимодействие приложений с пользователем, но и пользователем являлись сами эти программисты, ибо компьютеры были дорогие и ни у кого другого их просто не было. Сейчас компьютеры есть у всех, но проектируют взаимодействие в подавляющем большинстве случаев, опять же, программисты. Что мы получаем: мы получаем отличные интерфейсы, которые очень хорошо коррелируют со внутренней структурой приложения, которыми превосходно пользоваться... ПРОГРАММИСТАМ! Остальным же пользователям практически нереально понять как использовать все это нагромождение.

Возникает вопрос "Почему?". Ответ прост: дело в том, что понятие "удобно" у программистов и пользователей -- разные. Вспоминаем что было в начале.

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

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

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

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

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

Итак: читаем, комментируем.

Читать дальше......

Знакомство с Bash

Не так давно судьба заставила перебраться на линукс, выбор коего пал на Kubuntu по соображениям лени. А так же потребовалось поднять CI систему на этом самом линуксе. Решено использовать с этой целью бbash. Пусть я и забиваю гвозди микроскопом, но зато много чего нового в этом деле можно выучить.

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

Собственно решение подвернулось следующее:
1) ищем все исполняемые файлы
2) все их выполняем и складываем возвращаемые значения (получим количество проваленных тестов. Не обязательно, но мне захотелось)
3) выводим результат. Если ненулевой, то пора паниковать, иначе -- все хорошо.

Пока получилось вот что:

files=$(find ./tests/ -executable -type f)

echo '************************'
echo '** executables to run **'
echo '************************'
echo

for x in $files;
    do
    echo $x
    done

echo
echo '*********************'
echo '** start execution **'
echo '*********************'
echo


result=$((0))
for x in $files;
    do
    $x
    result=$(($result+$?))
    echo
    done

if [ "$result" != "0" ]
then
    echo **********
    echo ** FAIL **
    echo **********
else
    echo
    echo '*************************'
    echo '******** PASSED *********'
    echo '*************************'
echo
fi
exit $result

итак по пунктам:

files=$(find ./tests/ -executable -type f)

создаем переменную files и записываем в нее вывод метода find.
параметры find:
./tests/ -- искать в папке ./tests/
-executable -- исполняемый файл
-type f -- указываем, что искать надо файлы

result=$((0))
for x in $files;
do
$x
result=$(($result+$?))
echo
done

Создаем счетчик result.
В цикле выполняем все найденные файлы.
Увеличиваем счетчик на значение возвращенное последним исполняемым файлом. Вот это самое '$?'.

if [ "$result" != "0" ]
then
    ...failed
else
    ...succeeded
fi
exit $result

Тут просто: выводим и возвращаем результат, для дальнейшего использования.

Вот примерно так. Надеюсь кому-нибудь поможет.

Читать дальше......