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

 

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

 

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

 

Продолжая тему про суровый бенчмаркинг сообщаю что через 20 минут мы (DRUM и Kim55) едем встречать вундеркинда последнего полугодия вольку или vow. На этот раз не нам предстаяла поездка в город суровых фрезеровщиков, а вольке предстояло ехать в город футбола с погодой около -30. Еще до наступления нового года я както позвонив вольке ляпнул что типа приезжайте с Максом (demiurg) теперь вы к нам, и Вова без проблем согласился...Теперь мы его встречать едем:). Очень нравятся такие люди которые без запар могут сорваться и все. Думаю в этот раз будет не меньшая порция радости нежели в прошлый раз в челябе. От себя хочу сказать, что меня лично начинает все больше привлекать такой вид бенчинга, когда нас собирается много. Поэтому могу сообщить что в ближайшие 2 дня будет лютая битва за медальки:) благо железа и азота будет завались.

 

 

Зачин

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

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

Работа

Что последовало затем ? Проектирование, объектно-ориентированное моделирование. Здесь мы представляли задачу, как построение механизма взаимодействия объектов, описывая их свойства и интерфейсы. Самая легкая, но самая главная часть: определить базовые классы, данные, в нужном виде: класс студента, списка студентов. Позже был выделен серверный студент, как наследник обычного, но с добавочным полем пути к фотке на сервере, для списка разработан интерфейс (в терминологии ООП JAVA) в целях расширяемости (подгружать ли список из файла, либо с БД, либо иным другим способом). Классы, для работы с изображениями, данными. Изначально решили, что тот же клиент будет существовать в консольном и GUI вариантах, причем GUI ничто иное, как фронтенд. Сервер построен на работе с селектором и каналами, т.е. все операции с сетью без блокировки. Взаимно-согласованные серверы, именно так это называлось в нашем курсе. Для генерации ответа опять же выделили интерфейс, который потом реализовали в отдельном классе. Здесь же распределили обязанности в реализации, разобрали работу протокола, сформировали все требования к нему. Далее технические средства реализации: Среда разработки Eclipse для JAVA, SVN-сервер нашей кафедры для синхронизации разработки. Ну что же, после оформления этих деталей началась разработка. Первым делом выложил приблизительный каркас проекта с пояснением роли каждого класса, раскидал все по пакетам. Выложил описание протокола с примерами, выложил распределение заданий, памятки по работе с SVN. Было сразу обговорено еще раньше, что в SVN нельзя коммитить некомпилируемый код, оставлять пустыми комментарии коммита, лезть в чужие классы без надобности, разве что разрешалось делать заглушки отсутствующих методов с TODO или FIXME. Это помогало избегать конфликтов в SVN до последнего. Я не хочу говорить, что кто-то не обладает необходимым багажом знаний, скорее опыта, поэтому модель задачи и реализация была упрощена, не требовалось знать те же паттерны проектирования и т.п., чтобы отведенное время не тратилось на перенастройку на новый, непривычный лад.

Ложка дегтя.

Какие были допущены ошибки (на мой взгляд):

• Необходимо было заранее согласовать некий фреймворк для конвертации данных, участвующих в программе. Результатом получилось, что два человека для своих классов в разных пакетах писали одни и те же служебные методы перевода буфера в строку и обратно (мелочи, а тратит время).
• Никогда не бывает много информации и детализации о проекте. Если одна вещь мне видится так, то не значит, что другой человек разделит мое мнение. На начальных этапах изменения в SVN не всегда согласовывались с изначальными планами.
• Нужно заранее ставить сроки окончания работы с запасом. Все мы люди, со своими заботами и проблемами. Выставленный срок оказался слегка затянутым, поэтому все кинулись коммитить уже под его конец (на 4-ый день из 6 поставленных резко возросла активность разработки).
• Под конец работы внимание рассеивается, так что некоторые вещи к релизу выглядят неожиданными и упущенными. Нужно всегда выбирать себе план по времени на каждую задачу. Если не успел - не добивать ее тут же, а перенести на максимально близкий срок после выполнения других.
• Всегда стоит относиться с уважением к чужому коду. Если что-то не нравится, то лучше рассказать, как надо, а не переписать и указать на новый вариант. Нужно интересоваться мнением всех участников, доверять им в некоторых вопросах безоговорочно. Благодарить за хорошую работу и вообще всяческое содействие. Ведь вполне ясно, что специфика проекта не предполагает, что кто-то получит от него сколь-либо значимую материальную выгоду. (вспомним опенсорс)
• Не стоит пытаться все сделать самому, а такое желание часто возникает: опять же из-за различного подхода к реализации, выборки мелочей.

Плоды трудов.

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

Послесловие.

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