Android tech blog

Генерация аналитических поверхностей карт

2012-01-18T09:13:00.001-08:00

Введение

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

Задача

Иметь возможность получить высоту в любой точке, имея две координаты: h=f(x, y); Координаты могут быть как географическими, так и линейными. Иметь возможность получать высоты с любым шагом координат в пределах машинной точности. Размеры карт от нескольких сотен километров, до тысяч, вплоть до всей земли. Операция получения высоты должна иметь сложность О(1) и выполнятся достаточно быстро для работы графического движка.

Исходные данные

Карты поставляются в различных форматах, поэтому выполнялась предварительная обработка. После обработки имеется карта изолиний (неравномерная сетка) земной поверхности в унифицированном формате: <Количество точек> <Высота> <Широта> <Долгота> <Широта> <Долгота> <Широта> <Долгота> <Широта> <Долгота> <Количество точек> <Высота> <Широта> <Долгота> <Широта> <Долгота> <Широта> <Долгота> <Широта> <Долгота> <Широта> <Долгота> <Широта> <Долгота> … Или в цифрах: 3 0.000000 32.071945 69.587814 32.074299 69.586975 32.070995 69.585907 4 0.000000 32.063576 69.578514 32.062050 69.578270 32.059124 69.578407 32.057785 69.579376 Изолинии могут быть замкнутыми и состоять из отдельных линий. Пересечения изолиний не допускаются, хотя используемый подход обработает и неверные данные. Также в большом количестве имеются одиночные точки высоты.

Содержание работы

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

Часть 1. Подготовка данных

Введение

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

Содержание работы

Часть 1. Подготовка данных Часть 2. Генерация равномерной сетки Часть 3. Создание аналитической поверхности

Цель подзадачи

Определить максимально эффективную детализацию неравномерной сетки, для сохранения деталей.

Алгоритмы

В данной части применяется достаточно простой подход к обработке данных. Предположим, в некоторой части карты у нас встречается несколько точек. Одни соединены и представляют изолинию. И еще одна точка расположена близко к изолинии, но имеет сильный перепад по высоте с ней. При простой обработке точек, после интерполяции часть изолинии изменит свою высоту на нечто среднее, между двумя высотами (Рисунок 1). Как Вы думаете, какая высота будет в точке, помеченной вопросительным знаком? Чтобы избежать искажений при перепадах высот, необходимо увеличить количество точек на изолинии. Рисунок 1. Начальные данные. Оптимальным вариантом является задание разрешения равномерной сетки на данном этапе. В этом случае можно контролировать качество генерируемой поверхности. Поэтому зададим разрешение сетки и дополним все изолинии точками по некоторому алгоритму, чтобы все точки изолиний стали неразрывными. Самый простой способ: линейная интерполяция. Просто добавляем точки в изолинию по алгоритму Брезенхема или подобному. Немного сложнее и требовательнее к ресурсам ЭВМ сплайн интерполяция на плоскости. Мы использовали кубическую интерполяцию. Очень важно использовать именно интерполяционные алгоритмы (новые элементы содержат все заданные точки), аппроксимация (новые элементы приближены к изначальным точкам) в данном случае будет лишь искажать данные. При высоком качестве исходных данных, даже линейная интерполяция дает прекрасные результаты.

Результаты обработки

После обработки неравномерной сетки ее размер на диске возрастает, где то в 3-5 раз, в зависимости от качества данных. Графически результат выглядит так: Рисунок 2. Линейная интерполяция.

Рисунок 3. Сплайн интерполяция c некоторым шагом. При использовании сплайн интерполяции (Рисунок 3), линия получается не прямой, так как принимается во внимание информация о положении крайних точек.

Выводы

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

Генерация аналитических поверхностей карт

2012-01-18T09:12:00.003-08:00

Введение

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

Содержание работы

Часть 1. Подготовка данных Часть 2. Генерация равномерной сетки Часть 3. Создание аналитической поверхности

Цель подзадачи

Необходимо получить равномерную сетку из имеющегося набора изолиний. При этом все высоты должны быть согласованы (плавные переходы). На месте изолиний высота не должна искажаться.

Алгоритмы

Существуют различные алгоритмы получения равномерных сеток. Все из них имеют свои достоинства и недостатки, как и приводящийся ниже пример. Так как равномерная сетка являлась промежуточным результатом работы, то ее создание проводилось заранее. Время работы алгоритма должно было укладываться в разумные пределы времени и расхода памяти. Полученный результат уже можно использовать для игровых приложений, так как его точность не настолько критична. Из предыдущей части мы фактически уже получили равномерную сетку с нужным разрешением, только большая часть высот на ней не вычислено. Эту задачу решает данная часть.

Рабочая карта

На рисунке 1 приведен пример равномерной сетки с незаполненными высотами. Цвет линии обозначает высоту, черный цвет - неизвестная высота. Рисунок 1. Рабочая карта

Общее описание алгоритма получения высоты в произвольной точке

Регионы

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

Расчет высоты

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

Поиск ближайших точек

В этом месте следует упомянуть о книге В. Порева "Компьютерная графика". В ней даются базовые понятия компьютерной графики и приводится хороший алгоритм поиска ближайшей точки. Называется он "Поиск по периметру квадрата". Оригинальный алгоритм ищет всего лишь две ближайшие точки, при этом возможны ситуации, когда найденные точки, частично или полностью, могут находиться за изолиниями от текущей. Вычисленная таким образом высота является неверной, поэтому алгоритм был расширен до трех точек с контролем пересечений с изолиниями. В этом случае исчезают, возникавшие ранее артефакты, в седловых точках (низина между несколькими доминирующими высотами) и на краях больших перепадов высот. Рисунок 2. Оригинальный алгоритм. Красным обведены артефакты. Рисунок 3. Модифицированный алгоритм. Весь код в статье приводить не буду, он будет дан ссылкой в конце статьи. Его там не много, комментариев для понимания достаточно.

Результаты обработки

В результате обработки получается равномерная сетка с необходимым разрешением. Пример приведен на рисунке 3. Она имеет плавные переходы между высотами. Вся карта с равномерной сеткой разбивается на регионы для уменьшения объема занимаемой памяти. Данные неравномерной сетки хранятся в списочных структурах.

Выводы

Генерация равномерной сетки достаточно ресурсоемкая операция, может проходить по несколько дней, в зависимости от требуемой точности и вычислительных мощностей. Алгоритм прекрасно распаралелливается, что позволяет проводить вычисления более эффективно. Использована модификация алгоритма В. Порева из книги "Компьютерная графика". Исходные коды интерполятора

Генерация аналитических поверхностей карт

2012-01-18T09:12:00.001-08:00

Введение

Точное физическое моделирование требует высокополигональных карт. Чем выше точность карты, тем больший объем памяти она занимает и тем больше приходится обрабатывать данных, чтобы получить высоту. Сплайновая интерполяция позволяет получить сетку любого разрешения, с любым, удобным в данный момент, шагом по широте и долготе.

Содержание работы

Часть 1. Подготовка данных Часть 2. Генерация равномерной сетки Часть 3. Создание аналитической поверхности

Цель подзадачи

Получить из равномерной сетки сплайновую поверхность, содержащую все исходные точки. Реализовать вычисление высоты по двум координатам с произвольным шагом.

Алгоритмы

Самой большой проблемой, при поиске алгоритма, было найти грамотное описание создания поверхности из связанных сплайнов (граничные условия), которые бы содержали все искомые точки карты высот (интерполяция). Также следует учитывать, что количество деталей на поверхности может только уменьшаться, относительно начальных данных. Достаточно вспомнить теорему Шеннона-Котельникова Отличное описание алгоритма создания сплайновой поверхности из карты высот приведено в книге Е. А. Никулина “Компьютерная геометрия и алгоритмы машинной графики”. В ней очень много теоретического материала и математики по данному направлению (есть и описание подходов к генерации поверхностей фрактальными алгоритмами, что дает возможность создавать объемные поверхности). Не буду приводить здесь математические выкладки и примеры кода, потому что математику можно найти в книге, а реализация будет приложена в конце статьи.

Результаты обработки

В результате обработки равномерной сетки мы получим достаточно большой файл с коэффициентами сплайнов:


1 33
 3.30000000000000E+0001  1.00000000000000E+0000 -1.51788304147970E-0018 -1.95156391047391E-0018 
 0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 

 1.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 1.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 2.16840434497101E-0019  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 2.16840434497101E-0019  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 

 1.50000000000000E+0002  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 

1 34
 3.40000000000000E+0001  1.00000000000000E+0000  8.67361737988404E-0019  2.38524477946811E-0018 
 0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 

 1.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 1.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 2.16840434497101E-0019  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 2.16840434497101E-0019  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 

 1.50000000000000E+0002  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 

1 35
 3.50000000000000E+0001  1.00000000000000E+0000 -2.60208521396521E-0018 -3.03576608295941E-0018 
 0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 

 1.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 1.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 2.16840434497101E-0019  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 2.16840434497101E-0019  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 

 1.50000000000000E+0002  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
 0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000  0.00000000000000E+0000 
…

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

Выводы

Возможность перемещаться по карте с любым шагом открывает большие перспективы по разработке прикладного программного обеспечения. Алгоритмы динамического изменения детализации ландшафта начинают работать в полную силу (L.O.D, MegaTexture). Высота вычисляется с постоянной сложностью (перемножение матриц). Далее можно создавать карты не в проекциях, а прямо на геоиде, тем самым моделировать с высокой точностью регион земли или всю поверхность земли. И все, на что хватит фантазии. Существуют и другие алгоритмы, позволяющие добиться такого результата. Все зависит от поставленных задач. Предложенный подход дает лишь повод для размышлений и небольшой толчек к решению поставленной задачи. Исходники генератора на Delphi7

Оптимизация ошибок

2012-01-18T09:11:00.003-08:00

Введение

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

Простые примеры

Рассмотрим два простых примера, на основе которых можно описать большинство происходящих ошибок: Point readPoint() { ... } Points readPoints() { ... } Придерживаясь правила не использовать исключения в своем коде, придется возвращать и обрабатывать некий результат: Point point = readPoint(); if (point != null) { ... } Points points = readPoints(); if (points != null) { ... } Но это абсолютно лишний код. Всегда можно забыть сделать необходимую проверку и привести систему в неработоспособное состояние. К сожалению такого кода встречается достаточно много, как в открытых проектах, так и в коммерческих разработках. Если функция возвращает null, то она не выполняет свои обязанности. Из сигнатуры функции понятно, что она возвращает точку или набор точек, но null - это не точка, поэтому функция нас обманывает. В некоторых ситуациях разумно возвращать специальное значение. Точка с нулевыми или отрицательными координатами мало подходит для таких задач. Система может быть расширена, и тогда точка попадет во множество нормальных точек, код начнет вести себя непредсказуемо. Можно придумать специальную точку. А вот вернуть пустой набор точек во второй функции вполне разумно в некоторых случаях: Points points = readPoints(); for (Point point : points) { ... } Цикл просто не выполнит ни одной итерации, функция обладает ожидаемым поведением.

Использование исключений

Теперь посмотрим, как выглядят эти же примеры с использованием исключений: Point readPoint() throws PointNotFoundException { ... } Points readPoints() throws CouldNotReadPointsException { ... } Были добавлены два новых типа исключений:

PointNotFoundException - возникает, когда не удается получить точку;
CouldNotReadPointsException - возникает, когда не удается получить набор точек.

Тогда новые функции будут использоваться так: try { Point point = readPoint(); ... } catch(PointNotFoudException ex) { ... } try { Points points = readPoints(); for (Point point : points) { ... } } catch(CouldNotReadPointsException ex) { ... } Мы спокойно реализуем бизнес-логику, а если возникает ошибка, то обрабатываем ее в отдельном блоке. Код становится более ясным и понятным.

Производительность

Теперь поговорим о производительности. Механизм исключений - это всегда дополнительные затраты производительности. Затраты уходят на его поддержку. Но эти затраты становятся актуальными только при возникновении ошибок. Что код делает 99,9% времени? Работает, а не обрабатывает ошибки. Зачем снижать производительность своего кода, вынося код обработки ошибок в бизнес логику, делая его трудным для сопровождения и менее стабильным? Рассмотрим пример на основе функции получения точки. Предположим, она считывает очередную точку из некоторой очереди. Вот как выглядит код без использования исключений: while (!queue.isEmpty()) { Point point = queue.readPoint(); if (point != null) { ... } } В этом примере проверка на null будет выполнятся всегда, при каждой итерации. Пример с использованием исключений: try { while (!queue.isEmpty()) { Point point = queue.readPoint(); ... } } catch(PointNotFoudException ex) { throw new QueueReadingException(ex); } Можно упростить код, разделив бизнес-логику и код обработки ошибок: try { while (!queue.isEmpty()) { processNextPoint(); } } catch(PointNotFoudException ex) { throw new QueueReadingException(ex); } void processNextPoint() throws PointNotFoudException { Point point = queue.readPoint(); ... } Сколько раз в процессе штатной работы будет инициировано исключение QueueReadingException? В коде без ошибок - ни разу! Где же тут затраты?

Поток данных из сети

Пример немного утрирован. Помните, что инициация исключения влечет за собой просмотр стека, всех вызовов, поиск строк, из которых был вызван данный код и создание объекта исключения(о-очень долго). Предположим, что вместо очереди у нас некоторый поток, который приходит из сети. При передаче могут возникать ошибки. В коде, не использующем исключения, этот факт будет проверятся постоянно, тем самым замедляя систему. При использовании исключений, инициация исключения не такая уж частая процедура. Например, затраты на одно сравнение равны единице производительности. Инициация исключения 5 единиц. Пусть очередь содержит 100 точек, с 10% вероятностью возникновения ошибок чтения. Получается, на сравнениях теряется 100 единиц производительности, на инициации исключений в худшем случае 50 единиц. Если же увеличивать количество точек в очереди, то разница будет только возрастать(для тысячи точек она равна уже 900 единиц).

Выводы

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

Была такая профессия

2012-01-18T09:11:00.001-08:00

Введение

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

О знаниях

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

Технические писатели

Чтобы более точно описать тему статьи, расскажу о технических писателях. Технический писатель, специалист, занимающийся документированием в рамках решения технических задач. Приходилось наблюдать за работой технических писателей. Они создавали не просто горы документов по некоторому изделию, они заполняли ими целые помещения. И все документы были составлены четко по соответствующему для них ГОСТ-у или другому регламентирующему документу. Они в них прекрасно разбирались и ориентировались. Фразы подбирались настолько четко, насколько это возможно. Язык использовался сугубо технический, не допускающий вольных трактовок. Ничего не напоминает? Программист занимается тем же самым. Использует некоторый технический язык, четко строит документ. Документ должен удовлетворять определенным техническим требованиям. Программист прекрасно разбирается в написанном. По сути, программист и технический писатель это одна и та же профессия. Специализация разная. Есть 1С-программисты, С++..., есть технические писатели (ГОСТ, ISO и пр.). Требования, стиль работы, сроки и процесс почти полностью совпадают.

Требования, требования, требования...

Получается, что на всех этапах создания продукта выполняется конкретизация требований. В самом начале, заказчик говорит: “Хочу ...(вставить свое: программу, продукт, бренд, денег)”. По сути на этом этапе уже существует та сущность, на которую будет потрачено еще много средств, времени и нервов. Дальше начинается длительный процесс уточнения требований, которые в своем воплощении и создадут продукт. После пожелания заказчика: “Хочу программу”. Разного рода специалисты, начиная от менеджеров, заканчивая администраторами уточняют технические требования. Требования становятся все точнее и точнее, конечным состоянием требований становится продукт, потому что только продукт может удовлетворить все требования к нему самому.

Конвейерная разработка

Почему программистов больше нет? Потому что Форд в свое время придумал конвейер. Современный цикл разработки ПО это конвейер. Программисты, архитекторы, дизайнеры, менеджеры, администраторы, технические писатели, тестеры занимают четко обозначенные места на пути ПО, выполняют некоторое небольшое действие(уточняют требование) и отправляют его дальше. Все это одна профессия, с небольшими элементами специализации. Я думаю, многие смогут припомнить несколько хороших примеров, когда специалист из одной области переходил в другую.

Выводы

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

Три слова о руководителе

2012-01-18T09:10:00.003-08:00

Введение

Как много руководителей встречается нам на жизненном пути. Приходится общаться с большими и маленькими руководителями, царями и царьками, настоящими профи и самодурами. Но как понять, с каким человеком будет приятно и интересно работать, а с каким работа может превратиться в ад?

Выбор

В равных условиях порой тяжело провести грань между нормальным и хорошим руководителем. Тяжело сразу выявить и плохого руководителя: уж очень хорошо они маскируются. Отличного руководителя еще поискать надо. Но факт остается фактом. С одними людьми нам работать легко (работа может при этом быть достаточно напряженной и сложной), а с другими каждый рядовой день превращается в каторгу. Чтобы понять, каков человек, с ним нужно не один пуд соли съесть. Но выбрать направление можно достаточно просто. Хороший руководитель должен характеризоваться тремя простыми словами: доступность, вовлеченность, простота.

Доступность

В современном компьютеризированном обществе еще достаточно часто возникают коммуникационные проблемы. Все эти проблемы прекрасно решаются, и их надо решать! Как на техническом уровне, так и на психологическом. Сколько случаев можно вспомнить, когда из-за недоступности руководителя, принимались неверные и недальновидные решения. Часто исполнитель не в курсе всех проблем, он делает свою работу. Руководитель - это прекрасный регулировщик, направляющий работу в нужное русло. Предвижу вопрос: "И сколько времени должен быть доступен руководитель?". Ответ: "Все время, пока идет работа". Если исполнители работают в других часовых поясах, могут работать ночью (у разработчиков это почти стандартная практика), то руководитель должен быть доступен минимум по двум средствам связи все это время. Да и почему я должен выходить из потока, откладывать работу на завтра, если моего руководителя нет на месте, он слишком занят...?! А ведь всего то надо уточнить одну небольшую деталь. Почему два? Очень просто: первое средство для решения стратегических вопросов, о которых должны знать другие люди (конференции, почта, чат комнаты и пр.). Второе - для решения оперативных вопросов (ICQ, skype, телефон, разговор и пр.).

Вовлеченность

Если руководителю безразлична судьба проекта компании или, даже, ма-а-ленького модуля, то с ним возникнут проблемы. Сравните возникающую мотивацию к выполнению работы:

Необходимо к 12 ноября создать модуль, его писало уже три разработчика. Сроки надо обязательно выдержать.
Будет круто, если ты присоединишься к разработке модуля. Твои навыки и знания помогут нам сдать его в срок.

В первом случае, руководитель выполняет формальную обязанность - просто распределяет работу. Создается впечатление, что ему неважно качество продукта, его удобство или новизна. Важным является только срок, так как руководитель сможет передать выше позитивный отчет. Во втором случае, некоторая "неформальность" (а она всегда возникает при тесном взаимодействии людей) просто затягивает работника приступить к работе. Он чувствует ответственность не перед начальством как таковым, а перед коллегами.

Простота

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

Выводы

Конечно можно сформулировать еще множество критериев хорошего руководителя. Но, кажется, что для каждого исполнителя, этот список будет разным. Для себя я выработал список из трех критериев: доступность, вовлеченность, простота. Любой отличный руководитель должен удовлетворять им. Не стоит вносить в критерии материальное положение компании, существующие взаимоотношения, иерархию и политику. В хорошем руководителе важны, прежде всего, личностные качества, все остальное это лишь шелуха. Мы сами выбираем, с кем работать.

Перечитывая Купера

2012-01-18T09:10:00.001-08:00

Речь пойдет о замечательной книге Алана Купера, Роберта Реймана, Дэвида Кронина "Об интерфейсе". В этой книге представлен огромный пласт знаний авторов, который открывает глаза создателям цифровых продуктов. Очередной раз перечитывая этот монументальный труд, нашел интересную фразу. Она как то ускользала от меня до этого времени:
You can put lipstick on a pig, but it's still a pig¹
(Свинья есть свинья, сколько ее ни крась) Какая точная формулировка мысли о "косметическом латании дыр" в современных продуктах. Web 2.0, облачные вычисления, распределенные сети, SAAS - это лишь модели реализации. Мало кто знает, какие цели имеет пользователь, работая с неким продуктом. Продукты эволюционируют, развиваются, меняются, перевоплощаются, но остаются далеки от пользователя. Может, Вы тоже красите очередную свинью? Взял себе на заметку. Периодически проверяю цвет своей хрюши. Может еще кому пригодится, чтобы создать очередной "магический интерфейс"² по Куперу.

Глава 1. Современное проектирование цифровых продуктов.
Глава 6. Шаг 4. Игра в волшебство.

Целеориентированый разработчик

2012-01-18T09:09:00.003-08:00

Введение

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

Проектирование

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

Цели

Имеется обычный работник. Он только выбирает себе работу или уже работает. Какие внутренние цели им движут и что на это влияет? Мне видится несколько основных целей:

Делать работу легко за разумное время;
Получать достаточное вознаграждение;
Быть компетентным;
Быть успешным;
Чувствовать свою важность.

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

Помощники

А теперь рассмотрим элементы рабочего процесса, которые помогают работнику достигать целей. Разделим их на безусловные и условные. Безусловные - всегда помогают достигать целей. Условные - помогают достигать целей при выполнении определенных условий. Типичный рабочий процесс исполнителя состоит из этапов:

Постановка задачи;
Понимание задачи;
Поиск решения;
Реализация решения;
Проверка решения.

1. Понятное исполнителю задание - безусловно. Грамотно и точно составленное задание, имеющее достаточный, для однозначного трактования решения, уровень детализации безусловно реализует ряд целей работника. Способ постановки задачи - условно. Технический прогресс не стоит на месте. Задачи можно ставить как в бумажном, так и в электронном виде. Способ постановки может как приблизить, так и отдалить работника от его целей. 2. Достаточное время для понимания и осознания задачи - безусловно. Прежде чем качественно выполнить задачу, исполнитель должен ее однозначно понять. Возможность получать консультации - условно. Консультации экспертов предметной области или более опытных коллег однозначно приблизят исполнителя к заветной цели. Если они конечно готовы оказать необходимую помощь на должном уровне. 3. Доступность ресурсов - безусловно. Наличие качественных средств связи и коммуникации, библиотеки - еще один плюс к целям работника. Наличие базы решений - условно. Очень сильно зависит от качества базы решений. 4. Легкость включения решения в контекст задачи - безусловно. Чем проще применить решение к задаче, тем лучше. Легкость решения - условно. Легкие решения не всегда приближают исполнителя к его целям. 5. Количественная оценка успешности решения - безусловно. Количественные оценки дают исполнителю уверенность в себе. Жизнеспособность решения - условно. Не все жизнеспособные решения являются таковыми. Достаточно абстрактно получилось. Далее будет приведен пример.

Последствия

Ежедневная невозможность достижения целей исполнителем влияет на его боевой дух, моральное состояние. Это заставляет его задумываться о смене места работы, а может даже профиля или профессии.

Из жизни

Возьмем, например, разработчика, так как мне это ближе всего. Его помощниками будут:

Модульные тесты;
Качественная кодовая база;
Новые разработки;
Непрерывная интеграция;
Проектный нянь (руководитель, который помогает ему во всем. Правда надо знать меру);
Качественные инструменты;
Работа в потоке;
Разумные сроки;
Дружная команда;
Хороший компенсационный пакет;
Точные и однозначные технические задания;
Наличие актуальной документации;
Создание современных систем;
Сложные и интересные задачи;
...

И это еще не все. По хорошему, надо проводить исследование. Та компания, которая реализует цели работников, будет поощрена качественным трудом, мощным кадровым фундаментом, а в целом успешностью на рынке. Кто сформулирует помощников для руководителя, менеджера, администратора?

Офисы мечты

Все уже знают как выглядит офис Google, Microsoft, Yandex или Vkontakte. В них целям исполнителей уделяется некоторое внимание, но, кажется, недостаточное. В данном случае играет роль уже престиж компании, который сам по себе реализует цель пользователя быть успешным. У них есть чему поучиться, но делать это надо с умом. Любой, наверное, сможет привести пример небольшой, небогатой, простой компании, без особых излишеств, в которой коллектив сплочен, крепок, целеустремлен. Такие коллективы продолжают общение вне ее стен. Но это зародилось в недрах компании, она смогла дать своим работникам то, что не смогли дать другие.

Заключение

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

Читайте код, с остальным справится компилятор

2012-01-18T09:09:00.001-08:00

Введение

Уже не в первый раз мне задают связанные вопросы: "Зачем ты делаешь так много функций?"; "Зачем ты выносишь, однократно используемый, код в функции?"; "Остальные не знакомы с твоими правилами именования функций. Как они будут с этим работать?". Поэтому опишу свое видение проблемы. Ну а сообщество подскажет, к чему же стоит стремиться.

Ситуации

В процессе работы встречается разный код. Его надо сопровождать, исправлять в нем ошибки, добавлять новый функционал. Также пишется новый код, с которым предстоит работать в дальнейшем другим. Опишу несколько ситуаций:

Ситуация №1 Код делает слишком много

В классе есть доминирующий метод размером чуть меньше самого класса, при этом она содержит в себе всю логику и инфраструктурный код;

Ситуация №2 Логика кода понятна только после его изучения

Код хоть и невелик, но что он делает понять достаточно сложно;

Ситуация №3 Добавляется новый функционал

Имеется достаточно сложный код, в который необходимо добавить новые функции;

Ситуация №4 Пишется новый код

Код должен иметь низкую связность, хорошее покрытие тестами, сопровождаемость и пр;

Причины

В каждой из этих ситуаций, я стараюсь сделать минимальный рефакторинг. Делаю код более понятным и простым. Чаще всего выношу код в метод. Если позволяет API, то делаю более сложные рефакторинги. Условные выражения, если они сходу не понятны, стараюсь вынести в метод с понятным названием. Всегда руководствуюсь правилом: "код необходимо читать, а не компилировать и выполнять", что вполне соответствует идеологии, описанной Фаулером. Каждая функция должна иметь хорошее название, если она делает не то, что описано в названии, ей должно быть подобрано новое имя. Комментарии, являющиеся переводом кода - излишни (Exception - Ошибка). Всегда стремлюсь оставить код менее пахнущим, чем он был до этого. О запахах кода можно прочесть у многих, в частности у Фаулера.

Последствия

Почти после каждой более-менее существенной правки, мне задают вопросы, описанные выше. Говорят, что код стал менее понятным, становится трудно найти нужную строку и пр.

Причины

На самом деле проблема кроется как в коде, так и в разработчике, который привык к коду.

Предлагаю провести эксперимент.

Возьмите неизвестный участок кода, который написан хорошо. Он должен иметь методы со сложностью меньше 5. Если вам будет тяжело читать этот код, то обратите внимание, что вы пытаетесь транслировать код. Проверяете, как будет выполняться программа, поэтому неудобства доставляет постоянное перескакивание с метода на метод. Вы компилируете и выполняете код в голове. Если код читать легко, то, скорее всего, вы больше внимания обращаете на сигнатуры методов, на их названия. Вы читаете код. Для кода, содержащего несколько функций со сложностью более 30 верно обратное (к примеру, более 100 строк). Его читать невозможно, зато выполнение может принести свои плоды. Если вы не собьетесь в пятнадцатом вложении условия на двадцатой итерации цикла... Удачи!

Заключение

Можно сказать, что чем проще код, тем лучше. Только если вам кажется, что ваш код прост, то его можно упростить еще на несколько пунктов. Ничего страшного, что функция сейчас используется в одном месте, ничего, что ее название более 20 символов. Главное чтобы код читался, можно сказать, как художественная книга. Именно код, а не комментарии. Хорошие примеры можно найти в трудах Гласса, Фаулера, Макконела, Мартина. Еще хорошим контролем качества кода являются тесты. Не в том смысле, что в нем не ошибок - ошибки есть везде. Если, при написании теста, вы задумались на пару минут о том, как тестировать код, то он, на самом деле, сложноват, его можно упростить. Порой, приходят настоящие озарения. Пишите и читайте свой код, а все остальное сделает компилятор!

Будем конструктивнее. Министерство Обороны РФ

2012-01-18T09:08:00.000-08:00

Введение

Политика политикой, но почитав сегодняшние новости на своем любимом ресурсе мне стало жутко обидно и стыдно за его пользователей. Речь идет о заметке Коммерция в Министерстве обороны РФ. Работа журналистов - распространять новости, а работа инженеров - сопоставлять факты и делать выводы. Что же мы видим в данный момент? Инженеры читают и слепо верят “желтым заголовкам”. Делают предположения из воздуха и сокрушаются, что всех обокрали. Позор! Я не удивлен, почему в последнее время наблюдается отток профессионалов с Хабрахабра. Нет смысла гадать на кофейной гуще, надо апеллировать фактами. Сообщество же все больше склоняется к флеймам и холиварам. Журналист, не подкованный технически, читая такое пустое, но активное обсуждение распространяет дезинформацию дальше, где ее уже никто не проверяет. Есть отличный ресурс “РосПил”, где можно, путем общих усилий, сохранить бюджетные деньги. Но почему же все “эксперты” не работают там? Очень просто - тут можно писать все что хочешь, а в суде нужны факты и доказательства.

Инженер, не политик

Инженер, в отличие от политика, всегда должен опираться на факты. Никакой предвзятости, никаких пустых слов, только факты. Ресурс у нас совсем не политический. Можно назвать его дискуссионной площадкой. Кто то описал проблему, подкрепил фактами, далее идет конструктивный спор, в котором, как известно, рождается истина. Но в споре приводятся факты, доказательства, аргументы, и только в самом конце, экспертное мнение. Помните, что когда журналист пишет “по оценкам независимых экспертов”, он имеет ввиду нас. Не будут же ради одной заметки нанимать кучу экспертов и проводить серьезное исследование. Нет и имен экспертов - сплошная анонимность. Поэтому надо “держать планку”.

Экспертное мнение

Экспертное оценивание - это достаточно трудоемкая процедура. Слабым звеном в нем являются специалисты. От их подбора зачастую зависит результат всего исследования. Оно может быть неверным, предвзятым, искаженным (групповое мнение). Поэтому к экспертным оценкам стоит прибегать уже после анализа всех фактов. И только для тех элементов, которые не могут быть оценены другим способом. Тем более не стоит верить мнению экспертов, которые не поучаствовали в создании минимум 3-х подобных системы от начала и до конца.

Разбор полетов

Давайте по порядку разберем самые критичные замечания и попытаемся определить их решения. Естественно опустим мнения, которые вообще не относятся к теме или заведомо несерьезны.

1. 404 ошибка на главной странице.

Да, серьезная оплошность. Но стоит учитывать, что 404 ошибка, это не 403, 408, 500 или любая другая. Не найдена страница. Явно где то ошибка, все доступно. Никаким хабра-эффектом тут и не пахнет. Конечно логичнее было показать статичную страницу “сайт на обслуживании” или подобную, реакция была бы гораздо адекватнее.

2. Сайт находится в режиме тестирования

Я солидарен с Купером. Сайт либо есть, либо его нет. Других вариантов быть не должно. Помните, раньше было популярно создавать множество разделов в заведомо мертвом сайте с содержимым “здесь скоро будут новости”, “страница находится в разработке”. Зачем они пользователю. Когда будет контент и функционал, тогда и стоит показывать его пользователям. Ошибки есть везде, их надо исправлять. Если пользователи используются в качестве тестеров, то надо иметь грамотную и простую систему обратной связи. Нашел ошибку, написал об ошибке в поддержку.

3. Четыре игры за большие деньги

Похоже никто не обратил внимание на слова автора: "На мой взгляд это образец успешности. Резделили между собой..." (орфография сохранена). В заметке нет ни одного факта, что все эти деньги были выделены именно на эти четыре игры. А значит, это пустые слова. На эти деньги могли сделать еще кучу различного функционала, изучить который на основе проектных документов или ТЗ ни кто не спешит. Думаю, на просторах интернета можно найти подтверждения по объемам проведенных работ. Тогда уже можно говорить, что было сделано, а что нет.

4. Объем штата

“Сегодня как раз с коллегой бурно обсуждали эту новость. На 36 млн рублей можно держать штат из 10-ти человек с зп по 100к 3 года! За 3 года они хоть WoW и не напишут, но сделают вполне себе продукт. Но это простите меня… так и слышен звук ножевок. Позор!” - работать надо, а не обсуждать работу других. Фактов снова нет. Стоит учитывать, что ниже в комментариях указывается, что поставлялось комплексное решение, с железом. Одной ЗП тут не обойтись. Кстати, за сколько долларов и какое количество разработчиков создали WoW? 30 человеко-лет - это не так уж и много. Брукс еще в те годы писал о системах, для разработки которых тратились тысячи человеко-лет.

5. Железо

В комментариях упоминается цифра в 16 серверов. Стоит учитывать, что помимо них еще потребуются коммутаторы, стойки, источники питания, дата-центр, приличный объем дискового пространства, километры кабеля, возможно, барансировщики нагрузки. Сколько это стоит? Есть специалисты по поставкам? Посчитайте сумму, желательно в интервале. Все цены должны иметь подтверждение. Может я завтра захочу собрат мини-хостинг у себя. Комментарии вида "Я за 2 тысячи долларов соберу вам такой сервер" - считаю просто глупыми. Во-первых, на таких серьезных проектов “самопал” использовать просто нельзя. Во-вторых, кто дал вам гарантию, что он не умрет на пиковой нагрузке через пару месяцев. Ко всему к этому, необходимы средства криптозащиты, ОС, инфраструктурное ПО, которое с торрентов не скачаешь.

6. Сравнение несравнимого

Сравнивать симулятор с порталом, как то не логично. К тому же автор комментария приводит ссылку на википедию, где в самом конце упоминается цифра в 2,5 миллиона долларов в год. Также есть информация, что программа-симулятор разрабатывалась с 2002 года по 2009. Это серьезные капиталовложения. Может найдется более подробная информация в сети по данному продукту?

7. Статический сайт-визитка

Все же это уже не просто информационный сайт. На нем есть видео, интерактивные элементы, карты, тесты, это уже больше похоже на портал. Если обратить внимание на содержимое сайта, то становится ясно, что это не очередной блог или презентационный сайт. Ресурс предназначен для военнослужащих и интересующихся тематикой. Возможно для гостей сайт прост, но для военнослужащих и прочих зарегистрированных пользователей открывается новый функционал(социальные элементы, документооборот, секретная связь по “нашему скайпу” :)). А уж там может быть все что угодно. Единственное место, где это все описано - ТЗ.

8. Другие упоминающиеся проекты

Приводите хотя бы ссылки, кто и что сделал. Что воздух то сотрясать? Вы их изучили? Провели анализ? Свели дебет с кредитом? Аргументируйте.

9. Хостинг на 500 рублей.

Ни один известный мне хостинг за 500 рублей не выдержит не то чтобы такой нагрузки, просто наличия такого функционала. Где арендовать 16 серверов с балансировщиком и инфраструктурой за эти деньги? Дайте ссылочку? Самый простой тест, чтобы изучить возможности системы. Проверьте ее под нагрузкой: 1, 5, 10, 100 тысяч пользователей. Сколько выдержит? А затем возьмите любой проект с известной стоимостью и сделайте то же самое. Сделайте выводы. Это уже будут не просто слова, это уже будут реальные показатели.

Конструктивная критика

Свежий взгляд всегда полезен, но пишите конкретику. Молодцы те, кто нашел ошибки в играх. А кто-нибудь в тех. поддержку написал? Давайте сделаем ресурс лучше. Это же все наше.

Заключение

Инженеры - это техническая элита. Давайте соответствовать. Меньше желтизны на страницах Хабра, меньше желтизны к комментариях. Доверяйте фактам, а не субъективному мнению человека без имени и фамилии, скрывающемся под псевдонимом. Критикуйте, спорьте, в этом и суть этого ресурса. Здесь все равны, каждый имеет слово. Главное, чтобы это слово не было пустым. Готов угостить пивом в Питере того, кто проведет комплексный анализ озвученных проблем по части mil.ru. А кто, если не мы? Сбербанк и остальные уже создают новые творения! P.S. Сами понимаете, что этот шумок может быть и не критикой вовсе, а простым пиаром, конкурентной борьбой и пр. Знаменитости часто мелькают в скандалах, просто чтобы их не забыли. Грамотный редактор может создать текст с любым эмоциональным оттенком. Думайте! Ресурсы: 1. Статья - http://habrahabr.ru/blogs/eCommerce/135955 2. http://en.wikipedia.org/wiki/America%27s_Army 3. http://mil.ru 4. http://ru-compromat.livejournal.com/461508.html 5. http://moscow-post.ru/politics/virtualnyj_raspil_v_minoborony8233/ 6. http://izvestia.ru/news/511261