Geoid

Земля имеет форму шара, Забавно видеть хуй омара. Азбука

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

Геоид- фигура, отражающая форму Земли, важное понятие в геодезии.

Помилуйте, геоид не имеет решительно никакого отношения к форме Земли. Более того, изобретать просто так фигуру «описывающую форму Земли» бессмысленно. Однако, математики давно прослыли чудаками и эта бессмысленность не бросается обывателю в глаза. Если вы приглядитесь к картинке, геоид довольно слабо напоминает форму Земли. Откуда же он взялся? На самом деле геоид имеет вполне практическое применение. Как вы все наверняка знаете, географические координаты (те которые широта и долгота) суть координаты сферические. Однако, поскольку земля не сфера и не эллипс, возникает вопрос: относительно какой сферы задаются географические координаты? Математики давно предложили работающее решение: использовать мнимый эллипсоид вращения как-то худо-бедно совпадающий с земной поверхностью. Для вычислений идеально, однако, стоя в чистом поле довольно трудно этот эллипсоид обнаружить. Он же математическая абстракция. Мудрые математики и тут не сплошали. Они расположили эллипсоид так, чтобы короткая ось его совпадала с осью вращения земли, в центр его совпадал с центром масс Земли или был смещен относительно него на какое-то расстояние. Из физики мы знаем, что ось вращения проходит через центр масс. Осталась малость, вычислить его положение относительно поверхности. Для это была проведена гравиразведка все поверхности земли и построен геоид — фигура на поверхности которой сила тяжести постоянна и совпадает со средней силой тяжести на поверхности моря. Этого достаточно чтобы определить центр масс геоида, который совпадает с центром масс Земли. Зная, где находится центр масс, мы можем поместить в центр земли эллипсоид (умозрительно, конечно) и использовать его для определения координат.

Half-life

Период полураспада для большинства нововведений составляет две недели. Вне зависимости от того в чем состоит идея: вести документацию в wiki или штрафовать за неположенное распитие пива. Каждый может припомнить несколько довольно хороших (или ужасных) идей, которые «не пошли». Связано ли это с тем, что идеи плохие? Нет, распадаются и вполне хорошие начинания. Со стороны видно, что внедрить что-то сложнее чем кажется. Любая система обладает некоторым запасом инерции и социальные системы не исключение. После того как программистам наказали указывать номер бага при коммите обязательно придется некоторое время следить чтобы это правило выполнялось. И лишь через какое-то время оно перейдет в разряд «здесь так принято». Никогда, ни одно правило не будет выполняться только потому, что оно есть. Время принятия зависит от того, насколько нововведение выгодно конкретным исполнителям. Дневные отчеты могут быть офигенно полезными для проекта и для компании в целом, но если программисты не видят в них смысла, они будут забрасываться при каждом удобном случае. В идеальном случае, когда все без исключения исполнители понимают, какую пользу им принесет нововведение, они способны сами его внедрить. На практике это случается довольно редко. Итак, несколько практических рекомендаций:

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

Alone

Принято считать, что в современном мире для любой серьезной вещи нужна команда. Поговорки-пословицы всякие: «один в поле, волкам на потеху», «семеро одного не боятся», «команда — все, остальное — волшебные пузырьки». Вроде бы, как само собой разумеется, что производительности одного человека ни для каких серьезных задач недостаточно, а вот команда это сила. Ещё бы, на один только чай команда тратит в день больше времени, чем один человек может удалить работе в неделю. Доходит до того, что привычный к командной работе программист смотрит на индивидуальную задачу и изрекает: «да тут мне одному на полгода». И действительно, провозится с задачей 6 месяцев. В то же время, за стенкой может сидеть человек, стабильно решающий подобные задачи за месяц каждая. Производительность лучших и худших программистов отличается примерно на порядок. Всякий имеющий доступ к метрикам может получить эти данные самостоятельно. Вопрос в том, за счет чего так получается и какую выгоду можно извлечь, если работать в одиночку. Самое очевидное, это работа с постановкой задач. Любую задачу можно решать разными способами. К тому моменту, как задача доходит до программиста через кучу промежуточных звеньев, она обрастает коркой фантазий, зачастую не имеющих никакого отношения к исходной проблеме. Например, клиент хочет, чтобы работающие с программой менеджеры не забывали о назначенных встречах. Можно реализовать управление встречами в программе, а можно обратить внимание, что в компании уже используется для этого Outlook с которым довольно легко интегрироваться. Аналогичные ситуации возникают и при внутреннем взаимодействии. Быстродействующий программист не станет ничего делать пока не выяснит, какую именно проблему он должен решить. Второе, это правильное использование готовых средств. Если собственное решение занимает три недели, а применение готового — несколько часов на чтение документации и пару дней на исправление багов в чужом решении, это сэкономит две недели. В другом случае, частное решение пишется за неделю, а на использование существующего могут уйти недели. Умение верно оценить, сколько времени займет переиспользование, а с сколько собственное решение и есть искусство быстрой сборки из кубиков. У быстродействующего программиста нет времени изобретать все свои велосипеды самостоятельно. На третьем месте — острая пила. Инструмент должен быть адекватен решаемым задачам. Это касается как языков и библиотек, так и окружения. В эту бочку и владение инструментами (от IDE до shell) и DSL, и метапрограммирование с кодогенерацией. Отдельные аспекты «заточки пил» освещены изрядно. Пилы быстродействующего программиста всегда острые. Если хотите готового чеклиста:

• Может ли исходная проблема быть решена более простым способом?
• Можно ли изменить условия задачи так, чтобы она решлась существенно проще?
• Есть ли для задачи готовое решение?
• Существует ли инструмент, позволяющий решить данную задачу быстрее?