Qt Software (так называется Trolltech после покупки компанией Nokia) выпустили бету новой кросс-платформенной IDE для работы с Qt - Qt Creator. На данном этапе среда поддерживает только компилятор gcc и дебагер gdb. Можно так же использовать Microsoft Visual Studio компилятор, но тогда не получится дебажить.
Qt Creator - это не попытка заменить Eclipse и Visual Studio: Qt Creator is not an Eclipse replacement, but instead a lightweight IDE designed specifically for cross-platform Qt development.
Qt Creator is not a Visual Studio replacement, but instead a lightweight IDE designed specifically for cross-platform Qt development.
Финальный релиз намечается на начало 2009 года. Подробнее можно почитать здесь.
Выглядит это так:
Самореклама: мой второй блог
воскресенье, 21 декабря 2008 г.
Qt Creator
суббота, 20 декабря 2008 г.
1+1=4
Недавно попробовали на работе использовать парное программирование. Я к этому относился довольно скептически, поэтому все получалось спонтанно и дало неожиданные результаты. Вместо того, что бы каждый решал свою задачу, два человека делают одно и тоже да еще за одним компьютером. Но полученное решение получилось намного лучше, чем каждый предлагал в отдельности (все началось со спора, когда каждый отстаивал свое). И большинство ошибок было выявлено сразу - пока один пишет, у другого есть возможность проверять. Так что дополнительные затраты, связанные с привлечением другого человека, окупаются значительно меньшим количеством ошибок и меньшей вероятностью рефакторинга. Самое главное в этом процессе - не отстаивать только свою точку зрения, так как это заведомо проигрышный вариант. Если приструнить свои амбиции (лично для меня, это довольно не легко), можно получить синергетический результат. Не зря говорят, что одна голова хорошо, а две - лучше. Этот принцип прекрасно работает в программировании.
Заинтересовавшись этим вопросом, почитал главу Совершенного кода, посвященную совместной разработке. Оказывается парное программирование и другие подобные методы (обзор кода), действительно дают большие преимущества, позволяют выявлять огромный процент ошибок, даже больший чем тестирование. В книге указанны конкретные цифры, но это очень специфично для каждого конкретного проекта.
Из этого можно сделать несколько выводов. Во-первых, командная работа, это не только когда несколько человек работают над различными подзадачами общей задачи. Командная работа - это еще коммуникация которая, если она хорошо налажена, позволяет достигать синергии. А методы совместной разработки способствуют этому. Во-вторых, стоит время от времени экспериментировать.
Самореклама: мой второй блог
пятница, 19 декабря 2008 г.
Бесконечные проекты
Навеяло постом про собеседования.
Несомненно важно, что бы люди, которых берут для выполнения проекта, были хорошими программистами. Но, из опыта участия в бесконечных проектах, даже самые талантливые программисты могут мощно рыть в ширину, а не в глубь. Просто потому, что нет четкой цели. В итоге, проект бесконечно толстеет, но так никогда не заканчивается...
вторник, 2 декабря 2008 г.
Рассуждения вместо уравнения
В "Математической смекалке" довольно красиво показано как решение задачи плавно вытекает из условия при помощи простых рассуждений и элементарных вычислений:
Если некоторое двузначное число прочесть справа налево, то полученное "обращенное" число будет в 4.5 раза больше данного. Что это за число?Дальше уже не сложно продолжить рассуждения и найти искомое число.
В условии задачи данных немного, но, искусно их используя, можно решить эту задачу одними "рассуждениями" примерно так:
1. Искомое число больше 10, так как оно двузначное.
2. Но оно меньше 23, так как 23*4.5 - число трехзначное.
3. Искомое число четное, так как при умножении его на 4.5 получается целое число.
4. Обращенное число по условию в 9 раз больше половины данного числа, значит, обращенное число кратно 9.
5. Так как обращенное число кратно 9, то сумма его цифр делится на 9, а данное число состоит из тех же цифр, что и обращенное, значит, и оно кратно 9.
...
понедельник, 1 декабря 2008 г.
Утренний артхаус
Сегодня в 5 утра ехал на такси на вокзал. Всю дорогу таксист рассказывал как он прикручивал индексацию на ассемблере для базы данных, хранящейся на 8-ми дюймовой дискете...
пятница, 28 ноября 2008 г.
Кризисный оффтоп: "увольнения"
То, что экономический кризис не коснулся меня лично, не значит, что его нет. Среди моих знакомых, работающих в банках и тому подобных организациях, уже есть пострадавшие, которых "уволили". Я не зря взял это слово в кавычки - странно называть увольнением, когда человека вынуждают писать заявление по собственному желанию. Я сужу со своей колокольни и поэтому не понимаю, что значит вынуждают? Что мешает человеку, отработавшему на одном месте больше года, отказаться писать заявление по собственному желанию? Страх, что в трудовую напишут какую нибудь гадость? Но насколько я знаю, написать гадость не так то просто, КЗОТ хоть как-то от этого должен защищать. Возможно дело именно в незнании своих прав и вынуждение - это эксплуатация работодателями этого незнания?
Получаются одни вопросы. Может ли кто-нибудь объяснить мне такое положение дел?
четверг, 27 ноября 2008 г.
Тестирование "белого ящика"
В большинстве случаев, когда говорят о тестировании программистами своего кода, упоминаются юнит-тесты. Когда говорят о юнит-тестах, обычно говорят об инструментах, организации и нужно ли вообще это делать. Но обычно никто не говорит о том, как именно нужно писать тесты. Просто запуск функции с некоторыми параметрами и получение ожидаемого результата еще не означает, что функция полностью работоспособна и завтра удастся повторить это действие с другими параметрами. Непонятно от чего отталкиваться, когда пишешь тест.
Пусть есть функция, которая получает длину сторон треугольника и возвращает его тип: равносторонний, не равносторонний или равнобедренный. В остальных случаях возвращается ошибка. Попробуем ее протестировать.// типы треугольников
enum type_t {t_scalene=1, t_isosceles=2,
t_equilateral=3, t_error=4};
type_t triangle_type(int sideA, int sideB, int sideC)
{
// проверка валидности треугольника -
// сумма длин двух любых сторон не должна превышать
// длину третьей стороны
if((sideA>0 && sideB>0 && sideC>0) && // 1
(sideA<(sideB+sideC))&&
(sideB<(sideA+sideC))&&
(sideC<(sideA+sideB)))
{
int ab = (sideA==sideB)?1:0; // 2
int ac = (sideA==sideC)?1:0; // 3
int bc = (sideB==sideC)?1:0; // 4
int num = ab+ac+bc;
// if num==0 - scalene
// if num==1 - isosceles
// if num==3 - equilateral
type_t types [] = {t_scalene, t_isosceles,
t_error, t_equilateral};
return types[num]; // 5
}
return t_error;
}
Функция состоит из трех частей - входящие данные, действия, выполняемые над ними и результат. Единственное, чем мы можем управлять в полной мере - это входящие данные, а результат служит индикатором. Тогда остается выбрать несколько подходящих наборов данных и следить за индикатором. Самое сложное - это понять, какой минимум параметров нужно передать, что бы найти максимум ошибок в коде (тестирование - это выявление ошибок, а не доказательство того, что функция работает).
Почему одного запуска функции и получение нужного результата недостаточно? Программы очень редко выполняются строчка за строчкой - этому препятствуют всевозможные логические операторы if, for, while, until, or, and, switch. Они разветвляют код, создавая сложные пути исполнения одной и той же программы при разных входящих данных. И по всем этим путям нужно пройти, один запуск с одними параметрами - это проверка одного пути из многих. Значит тестов нужно не меньше, чем перечисленных выше ключевых слов в коде. (В рассматриваемом случае под тестами я понимаю вызов функции с различными наборами параметров.)
Первый if, в приведенной выше функции, проверяет четыре условия - длины сторон треугольника должны быть неотрицательными и длина каждой из сторон должна быть меньше суммы длин двух других. Все условия объединены операторами &&, поэтому достаточно невыполнения одного из них, что бы не выполнился код, следующий за if. Но неплохо бы знать, все ли условия вычисляются правильно. Поэтому нужно передать функции значения, которые будут true и значения, которые будут false для каждого из условий. Проверить это можно по возвращаемому значению t_error, в случае если любое из условий не выполняется. Хотя первое из условий является само по себе составным, но все проверки в нем довольно простые и объеденены оператором &&, поэтому допустим, что достаточно будет проверки, когда одна длина отрицательная и когда все длины положительные.
В случае успешного прохождения if, выполняются проверки, помеченные как 2, 3, 4. Они не создают больших ответвлений, но вычисляют значения, которые влияют на выбор нужного элемента массива types в строке 5. Количество выполненных условий записывается в переменную num, которая может принимать только три значения 0, 1, 3 (2 не может быть, так как при выполнении двух автоматически выполняется третье). Значит для тестирования этой части кода достаточно 3-х наборов входящих параметров - все стороны неравны (num==0), все стороны равны (num==3), равны только 2 стороны (num==1).
Больше ответвлений в программе не наблюдается, поэтому можно подводить итог. Для тестирования функции triangle_type, нужно передать ей 14 наборов входящих параметров (8 для условия 1, 6 для условий 2, 3, 4) и проверить возвращаемый результат. После этого можно быть уверенным, что в большинстве случаев поведение функции будет предсказуемым. Хотя нет... это только часть возможных проверок. Еще можно проверять передаваемые параметры, например, как будет вести себя функция при максимально и минимально допустимых значениях, но это уже отдельная тема. Я хотел рассказать только о тестировании, базирующемся на изучении кода. Это как раз то, что теоретически отличает тестирование программистами от тестирования тестировщиками - программисты тестируют не "черный ящик".
PS: Не смотря, на то что получилось много текста, на практике это занимает не так уж много времени :)
