Тест Джоэла

Есть такой интересный тип Джоэл Спольски который ведет блог Joel on Software некоторые интересные записи можно почитать на русском с ресурса http://russian.joelonsoftware.com, часть записей попадает на хабр, ну или в виде книг Джоэл о программировании, Джоэл. И снова о программировании.

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

Тест Джоэла

  1. Пользуетесь ли вы системой управления версиями исходного кода?
  2. Можете ли вы выполнить сборку продукта за один шаг?
  3. Выполняете ли вы ежедневную компиляцию?
  4. Ведете ли вы базу данных ошибок в программе?
  5. Исправляете ли вы ошибки, прежде чем писать новый код?
  6. Есть ли у вас актуальный график работы?
  7. Есть ли у вас спецификации?
  8. Создали ли вы спокойные условия для работы программистов?
  9. Стараетесь ли вы использовать для работы лучшие из существующих
    инструментов?
  10. Привлекаете ли вы к работе тестеров?
  11. Предлагаете ли вы соискателям рабочих мест написать во время собеседования код?
  12. Проводите ли вы проверку «юзабилити» на случайных людях?

Небольшой комментарий от автора:

Что привлекает в тесте Джоэла, так это возможность быстро ответить «да»  или «нет» на каждый вопрос. Не надо вычислять количество строк кода,
выдаваемых за день, или среднее количество багов на каждую модифика
цию программы. Добавьте себе одно очко за каждый ответ «да». К сожалению, тест Джоэла явно не подходит для проверки надежности программного обеспечения, написанного для работы атомной электростанции.
В идеале вы должны набрать 12 очков. 11 очков – терпимое количество,
а 10 или менее указывают на серьезные проблемы. Фактически большинство софтверных организаций работает, имея лишь два или три очка, и они
нуждаются в серьезных улучшениях, потому что такие компании, как Microsoft, постоянно держат 12 баллов.
Конечно, успех или поражение определяются не только этими факторами. В частности, если у вас прекрасная команда, которая работает над никому не нужным продуктом, то он так и останется никому не нужным. И наоборот, можно представить себе команду «гангстеров», не соблюдающих ни одного из перечисленных правил, и все же умудряющихся произвести поразительную программу, переворачивающую мир. Но, при прочих равных условиях, если эти 12 пунктов выполняются, значит, у вас есть дисциплинированная команда, способная стабильно выдавать готовый продукт.

Более развернутые коментарии автора читайте в источниках приведенных выше.

Boost сериализация и QString

Время от времени кому то в голову приходит мысль использовать boost сериализацию в проектах с Qt. Тут встает вопрос как быть со строками, т.к. хочется просматривать  и редактировать.

Просто приведу пример кода без объяснений, думаю что все и так знают как можно работать с юникодом

namespace boost
{
    namespace serialization
    {

        template<class Archive>
        inline void save(Archive& ar, const QString& s,
                const unsigned int /*version*/)
        {
            auto ba = s.toUtf8();
            std::string str(ba.data(), ba.size());

            ar << make_nvp("QString", str);
        }

        template<class Archive>
        inline void load(Archive& ar, QString& s,
                const unsigned int /*version*/)
        {
            std::string str;
            ar >> make_nvp("QString", str);
            QByteArray ba(&str[0], str.size());
            s.append(ba);
        }

        template<class Archive>
        inline void serialize(Archive& ar, QString& s,
                const unsigned int file_version)
        {
            boost::serialization::split_free(ar, s, file_version);
        }
    }
}

Дампим Telnet/CLI сессию, для последующего анализа

Продолжая темы: пишем заглушку для Telnet/CLI, пишем заглушку для Telnet/CLI на Perl.

Студент попался нерадивый и не знает как сделать дамп/трассировку telnet сессии. Приведу два примера: средствами утилитами командной строки GNU/Linux, и средствами Perl.

Командная строка GNU/Linux

netcat host 23 | tee dump.dat

Тут мы использовали netcat и tee, netcat используем для получения сырых данных, включает управляющие символы telnet, tee утилита которая перенаправляет входящий поток данных в stdout и файл.

Средствами Perl

Тут мы пользуемся пакетом Net::Telnet в конструкторе которого можно указать логировать вход(Input_log), логировать выход(Option_log)

Пример:

#!/usr/bin/perl 

use 5.010;
use strict;
use warnings;
use Net::Telnet;

my $session = new Net::Telnet (Host=>"host", Input_log=>"input_dump.dat");
$session->cmd(...);
$session->close;

Пишем заглушку для Telnet/CLI на Perl

В Пишем заглушку для Telnet/CLI в качестве сервера выступал tcpserver из пакета ucspi-tcp. Раз уж использовал Perl, то приведу пример как можно сделать на чистом Perl.

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

Стоит дополнительно отметить, что после создания нового соединения, Net::Server переключает дескриптор сокета, на дескрипторы stdin и stdout, делая возможность читать из сокета привычным <>, а писать привычным print или say.

#!/usr/bin/perl

package MockServer;

use 5.010;
use strict;
use warnings;
use base qw(Net::Server::PreFork);

sub process_request
{
    while(<>)
    {
        chomp;
        if(/quit/)
        {
            say "bye";
            return;
        }

        print `$_`;
	}
}

1;

Net::Server::PreFork это реализация Net::Server использующая pre-fork модель обработки соединений, т.е. создается N процессов(ну, нет нормальной многопоточности в скриптовых языках Perl/Python/PHP) каждый из которых может держать по M соединений.

Реализация сервера:

#!/usr/bin/perl

use 5.010;
use MockServer;

my $server = MockServer->new(port=>23023);
$server->run();

Пишем заглушку для Telnet/CLI.

Сейчас работаю на контору, которая занимается мониторингом сетей передачи данных и сетевого оборудования. Одному из студентов на полставки было получено разработать компонент, получающий характеристики с одного устройства по CLI(Command-line interface) через Telnet. Все вроде как шло хорошо, пока не дошло дело до тестирования.

Студенту сразу же захотелось протестировать свой код на боевом сервере, видите ли ему нужна реальная железка. Естественно он был послан в песочницу, где он должен сделать заглушку.
Естественно я не могу требовать от других то, что не могу сделать сам. Привожу пример такой заглушки без всяких сокетов!
Будем использовать мощь UNIX-way в GNU/Linux.

Есть такой крутой man Daniel J. Bernstein, который помимо всего прочего написал пакет ucspi-tcp, это набор утилит с интерфейсом командной строки, для разработки клиент-серверных приложений.

Чувствуете мощь *nix систем ? Клиент-серверное приложение на bash’e !

Будем использовать программу tcpserver, а вместо баша любимый Perl, вот так выглядит её интерфейс:

tcpserver opts host port prog

opts опции запуска, host хост на котором будет висеть сервер, port порт на котором будет висеть сервер, prog наш скрипт или программа.

Как это все работает? tcpserver вешается на выбранный хост и порт, и начинает принимать входящие соединения. Когда кто-то к нему подключается, то он переключает дескриптор сокета на дескриптор 0 для чтения, и дескриптор 1 для записи и запускает программу prog. Для тех, кто не в курсе:

  • 0 — это дескриптор стандартного входа(stdin);
  • 1 — это дескриптор стандартного выхода(stdout).

Нам остается только лишь написать скрипт/программу которая читает строку их stdin, в зависимости от команды генерируем ответ в том виде, в каком отвечает железяка. В качестве примера привожу простой скрипт на Perl, считывает команду, если это quit, то выходим, иначе запускает команду и выводим результат на экран:

use 5.010;
 
$|=1;
 
while(<>)
{
    chomp;
    if(/quit/)
    {
        say "bye";
        exit(0);
    }
    
    print `$_`;
}

Запуск сервера:

tcpserver localhost 23023 ./cli.pl

Проверяем, подключаемся по telnet и получаем информацию о процессоре:

$ telnet localhost 23023 
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
cat /proc/cpuinfo