Тестовое задание для программистов, желающих вступить в Gipat Group.

v 0.1

Среды разработки - можно брать любую:

• Delphi (очень рекомендуется 6 версия)
• Borland C++ Builder (аналогично рекомендуется 6 версия)
• Microsoft VisualStudio (Версия 7 и выше, в принципе можно и 6-ю использовать для тестзадания, но бОльшая часть софта у нас компиллируется в 7 версии, даже то что изначально было в 6 и под 7 не хотело компилиться - для работы вам в любом случае потребуется 7 и выше).
• CodeBlocks + либо gcc+wxWidgets\gcc+WinApi, либо + бесплатный мелкомягкий компилер + MFC\WinApi. В этом случае вы должны быть в состоянии перевести под CodeBlocks и заставить компилиться проект, изначально разрабатывавшийся под студию. Я сам не пробовал, но грят что с мелкомягким компилером вполне можно компилить проекты под студию.
• Lazarus.

Собственно задание - пишется программа, в которой есть:

• Окно - там прогрессбар, кнопка "копировать", кнопка "отмена", пустое квадратное поле (дабы туда потом можно было выводить OpenGL или Direct3D графику)
• При нажатии на кнопку "копировать" выводит диалог открытия файла.
• Если юзверь выбрал файл - выводит диалог сохранения файла.
• Если юзверь сохранил файл - проверить - не тот же это самый файл который был открыть. Если тот же самый - сказать что нифигга и так неззя - и опять вывести диалог сохранения.
• Если не тот же и на месте сохраняемого файла уже что-то есть - спросить - хочет ли юзверь перезаписать файл (да\нет\отмена).
• Если ответит что нет - спросить куда сейвить. Если отменит - остановить все, оставить на экране окно с кнопкой чтоб опять нажать можно было. Если ответит да - продолжаем.
• Прога копирует файл по пути 1 (открытый файл) в путь 2 (сохраненный файл) заменяя его если он там есть. Информация о процессе копирования выводится в прогрессбар. Процесс копирования происходит в другом thread - т.е. не в том которое занимается перерисовкой окна. Скорость копирования должна быть вразумительной - примерно такой же как и скорость копирования через explorer, по крайней мере отставать от него незначительно. Окно с индикатором не должно подвисать.
• Кнопка отмены - вне процесса копирования она всегда заблокирована. В процессе копирования - разблокируется и если юзверь нажмет - копирование отменяется, причем немедленно - скорость реакии должна быть примерно такой же как и скорость обновления инфы в прогрессбаре.
• OpenGL или Direct3D графика. Рекомендуется использовать OpenGL. Для работы с расширениями OpenGL настоятельно рекомендуется использовать библиотеку glew. Если Direct3D - то пользоваться версией DirectX не выше 9.0c. В прямоугольнике в окне (о котором сказано в 1-м пункте) - выводить какую-нибудь фигуру на ваше усмотрение - только не шарик плз - должно быть возможно увидеть что оно двигается. Вне процесса копирования - оно крутится справа на лево. Во время копирования - слева направо.
• Информацию о настройках программы - расположение окна на экране, путь по которому запускалось в последний раз, путь к последнему скопированному файлу (точнее 2 пути - откуда и куда копировалось) - сохранять и подгружать (при запуске проги) из файла лежащего в папке с программой. Файл обязательно должен быть бинарным - тоесть не текст который можно открыть в блокноте (да, я в курсе что это нелогично, но надо же проверить ваши навыки работы с бинарными файлами) - например циферки инфы о расположении окна писать в файл не текстом а значениями байтов... формат этого файла должен быть масштабируемым - туда должно быть возможно добавить новые поля с информацией (достаточно полей типа string, float, integer, byte) - на случай если программе придется работать с новыми настройками. В формате файла также должна быть предусмотрена информация о версии формата, а в программе - механизм для чтения форматов устаревшей версии. Реализация механизма работы с этим файлом - в виде класса, свойства которого содержат информацию из файла (при желании можно поизвращаться и заинкапсулировать все свойства, оставив public только методы их чтения\записи - но я не сторонник подобной потери времени там где это в принципе не нужно), а методы - умеют читать и записывать инфу в файл.
• Выполненное тестзадание должно представлять из себя 2 архива. В первом - папка с бинарниками (имя папки должно содержать имя проги и версию - например !TestWork_0_1) - там все файлы, необходимые для их работы. Во втором - папка с исходником (имя папки = [имя папки с бинарником]_src) без всякого мусора вроде *.obj или бекапов файлов - тоесть только необходимое для открытия в IDE и сборки бинарников. Очень жалетельно чтобы средствами IDE было организовано нормальное раскидывание генерируемых при сборке файлов - например после build все что должно попасть в архив с бинарниками - складывается в отдельную папку, остается только заархивировать. Исходник должен сопровождаться readme с подробной инструкцией по сборке. При желании можно написать и readme для бинарников.

Что буду смотреть при проверке задания:

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