среда, 18 января 2012 г.

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

Введение

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

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

Введение

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

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

Введение

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

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

Введение

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

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

Введение

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

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

Введение

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

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

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

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

Введение

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

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

Введение

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

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

Введение

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