К сожалению прям вот взять любой сайт и запустить его на GAE не получится, нужно делать именно под него, на Python или JVM, и нужно хорошо понимать как это работает. Я смотрел лишь связку Python + Django. Многие преимущества Django тут отсутствуют (например знаменитая админка django), но тем не менее результат получается очень быстро и вполне качественно. Для JVM есть многообещающий Gaelyk, ну и куча прочих framework’ов.

Плюсы

• бесплатен для небольшого проекта, и очень подходит для стартапов, с непостоянной посещаемостью. 2-3 тысячи посетителей в день обошлись в 10 центов, на совершенно не оптимизированном сайте. На нормальном должно держать тысяч 5, хотя зависит от структуры сайта, на каком-то сайте и пара сотен упрется в такой предел
• очень масштабируемо, автоматически. Мо;но не боятся слэшдот/дигг/хабра-эффектов, все выдержит.
• готовая обвязка инструментами и сервисами:
• мониторинг текущей загрузки
• версионность приложения (может работать одновременно несколько версий, можно к примеру тестировать новую версию, пока пользователи видят лишь предыдущую)
• готова вся работа с пользователем (через Google Accounts), не нужно заморачиваться с регистрацией, защитой от ботов, сменой и восстановлением пароля и пр. пользовательских данных,проверкой прав и т.д.
• cron, message queue, отправка писем, работа с графикой и web-ом

Минусы

• хостит только поддомен, т.е. домен второго уровня прицепить не получится. поэтому все сайты в виде www.* Причина в том что GAE распределенн по разным датацентрам, и автоматическую балансировку трафика они могут сделать лишь для поддомена. Не известно будут ли они решать эту проблему, это хоть и всем не нравится, но жить с этим вполне можно.
• нет поиска, что для компании, изначально на это делающей ставку, вообще странно. Мне даже в голову не могло придти что у Google не будет поиска, и ничуть не смутило то что не увидел этого в презентациях, ведь это само собой разумеющееся. Но факт: поиска нет.
• нет нормального админского инструмента для работы с БД. Есть некий GQL, но этого не достаточно, он не поможет если вам нужно быстро найти пару «плохих» записей чтобы поправить вручную. Не заработает, например, потому что скорее всего для вашей ситуации (условия выборки) не будет индекса, а без индекса запрос не выполнится. Нормально пролистать, отсортировать и пр. тоже не получится. В общем чтобы полноценно админить БД придется писать код, с нуля, так как стандартная админка Django не работает
• нет полноценной отладки, не посмотреть логи с ошибкой. К тому же SDK и боевой сервер иногда по разному себя ведут на одном и том же коде, так что это проблема. Спасает лишь то что одновременно могут быть задеплоены несколько версий, одну видят обычные пользователи, вторую вы можете самостоятельно протестировать, не показывая пока не убедитесь что все работает.

Самый известный, наверное, подход к cloud вычислениям это mapreduce, и он прекрасно здесь организован. А так как этот mapreduce не всем понятен, да и не всегда нужен полностью, то здесь помимо него предлагается своя реализация java.lang.concurency.ExecutorService который разбрасывает переданные вычисления по кластеру.

В отличии от того же Hadoop здесь не гнались за обязательной возможностью обрабатывать терабайты данных за один проход. GridGain удобней будет для длительных вычислений на объемах гораздо поменьше, по хорошему это то что можно передать между нодой в одном List’е, что, возможно, даже практичней. Я не хочу сказать что для больших объемов эта платформа не подойдет, просто при большом объеме данных (а не вычислений над ними) все упирается уже в хранилище данных, и они этим сознательно не занимались, но в случае когда это нужно – можно всегда использовать и внешнюю БД и даже Hadoop HDFS/HBase.

Для многих случаев это очень удобный вариант, отличная альтернатива hadoop’у, ну в самом деле не обязательно у нас что-то грандиозное, вполне может быть у нас пара тысяч независимых операций и cloud из нескольких серверов, и этот самый простой способ распараллелить все. Если основной упор на вычисления, например параллельно обработать несколько тысяч url’ов, на каждый по 1-2 минуты, то GridGain предлагает очень удобное подспорье. И, кстати, очень просто организуется архитектура для случая когда есть несколько gui клиентов, на слабых компах, а все вычисления для них производятся в cloud.

Как я уже говорил платформа давно развивается (кстати нашими соотечественниками), хорошо документирована, внутренняя часть уже вполне стабильна, и к тому же хорошо развиты инструменты мониторинга, алгоритмы балансировки, восстановления после сбоя и пр. и пр. Для ознакомления стоит посмотреть скринкаст «Grid Application in 15 Minutes»

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

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

В итоге получаем примерно такие шаги:

1. (первая колонка) список URL
2. выкачиваем документ по этому адресу, складываем в колонку 2
3. убираем весь мусор (стили, js, реклама и пр.) из html и кладем в колонку 3
4. вырезаем текстовые контент (убираем навигацию, и пр.), результат в колонку 4
5. делаем PDF, результат в колонку 5

Рис 1. Таблица с несколькими колонками

Рис 2. Таблица с вертикальной обработкой

Мы складываем в колонку справа если у нас идет обработка 1 к 1 (см. рис 1), если же у нас идет какая либо вертикальная агрегация (см. рис 2), то новые данные стоит записывать под текущим блоком, в той же колонке, что есть более универсальный подход. В случае СУБД у нас получается для первого варианта таблица с колонками block_id, data_id, col_1...col_N, для второго варианта block_id, data_id, value. Где

• block_id это у нас идентификатор обрабатываемого блока,
• data_id идентификатор элемента данных, которым мы оперируем,
• и col_1..col_n или value это те данные которые нужно обработать.

В случае файловой системы получается только второй вариант, идентификатором тут будет путь к файлу. Следуя этим подходам в Apache Hadoop есть HDFS для варианта хранения в файлах, и HBase для хранения в виде таблицы.

Наверное сразу возникает претензия что у нас всегда данные если не дублируются, то остается слишком много временных данных, старые на каждом этапе остаются, а новые (выведенные из предыдущих) складываются рядом. Зачем это? Затем что иначе нам нужно следить за транзакциями, усложнять процесс распараллеливания обработки. Гораздо проще складывать рядом, и когда придет время (например когда мы дойдем до конечного шага), можно будет выкинуть все лишнее. Если мы можем позволить себе это, то так получается гораздо удобнее. Дополнительные бонусы тут в том что на любом этапе мы можем переиграть обработку заново (как замена rollback’а) или сделать новую «ветку» обработки, выполнив другие функции. И, как минимум, всегда можем проследить историю операций.

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

Так вот, хоть как язык Java и проигрывает, но она имеет за плечами огромный набор библиотек, для решения почти всех востребованных задач. Я бы даже выразился так:

На каждую хитрую задачу найдется свой jar с винтом.

ну может не всегда именно jar, а скорее технология, протокол, спецификация, но суть в общем такая.

У всех остальных все хуже. Там или узкая заточенность под одни нужды (RoR), или единая линия партии (.Net), или просто полный хаос.

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

Поэтому нравится java или нет, но… но чаще всего выбирать и не из чего.

P.S.: Хотя, если честно, есть тут один минус: это то что привыкнув к этому все стараются делать «через жаву», что не всегда верно, но это уже издержки производства.

где:
α — доля вычислений которые могут быть произведены только последовательно,
p — размер кластера (ну или количество процессоров/вычислителей).

И чем меньше α тем ближе масштабируемость к линейной. При 10% последовательного кода, к примеру, выходит что больше чем 100 компьютеров использовать не имеет никакого смысла, никакого серьезного прироста не будет, хоть на 1000 запускай. И добиться этих 10% не всегда просто.

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

Так вот MapReduce это такой подход построения архитектуры при котором просто не получится написать не параллельное приложение, α будет близко к 0. Алгоритм разбивается на 2 слоя параллельных операций и, в итоге, очень хорошо масштабируется. Надо заметить что алгоритм в виде функции map+reduce может быть гораздо медленней чем он же в стандартном (имеющим последовательные участки) виде, но стандартный алгоритм будет иметь предел после которого добавляя процессоры мы не выигрываем в производительности, с map+reduce вариантом этот предел почти недостижим. Дополнительным плюсом здесь является независимость, и при сбое отдельного участка его можно вычислить заново, не перезапуская весь процесс.

Map в данном случае независимо обрабатывает входящие блоки данных. Но хоть сами входящие данные не зависят друг от друга, то результат обработки часто зависит от их связей между собой. Обработкой первоначально независимой информации занимается соответственно Map, он подготавливает блоки данных для обработки, обработкой итоговых, уже зависимых друг от друга, данных займется Reduce.

Один из классических примеров использования mapreduce – подсчитать распределение слов. В этом случае map обрабатывает входной текст, как независимые блоки. На выходе получаем пары «слово — кол-во употреблений» . В простейшем случае map не анализирует текст, а лишь разбивает по пробелам, в итоге из текста 5 раз содержащего слово «hello» на выходе будет не пара «hello — 5», а 5 пар по «hello — 1». Вот этот выхлоп уже связан друг с другом, и reduce обрабатывает эту связь. Ему на вход приходят блоки с одинаковым ключем пары, он в свою очередь суммирует цифровые значения этих пар. Поэтому обоих случаев наших «hello — x» он выдаст «hello — 5». Основную работу тут выполняет reduce. Такой, не совсем простой, способ подсчета количества слов полезен когда объем анализируемого текста измеряется гигабайтами (и более). Map выдаст огромный файл отсортированных пар «слово — количество» Так как он отсортирован то пробегая по нему достаточно просто вызвать reduce для всех групп с одним ключом, и получить суммарное количество для каждого из слов.

Хочу заметить что mapreduce, конечно, не панацея, часто он совсем не оптимален, и для малых объемов вообще не имеет смысла, но это самое простое и универсальное решение для масштабируемых алгоритмов, хорошо подходящий для различных data mining решений.

А мне всегда как то хватало связки Spring + Hibernate + Tomcat/JBoss, что в сущности дает тоже самое, но удобнее. Список можно продолжить добавив еще как минимум Acegi, AspectJ, и прочие решения умеющие хорошо и удобно решать свою отдельную задачу, многие легко взаимозаменяемы и дают очень неплохой синергетический эффект.

EJB немного был когда я работал в Luxoft, но это почти мимо меня прошло. К EJB как таковому у меня отношение отрицательное из-за больших объемов лишней работы, я считаю что простые вещи должны делаться просто. Для EJB это не выполнялось, простые вещи делались сложно. Да и, честно говоря, сложные вещи делались не сложно, а очень сложно. Тоже самое касается и JSF. Система становится всеобъемлющей, делает все что можно, но, как результат комплексности, делает «все» одинаково плохо. Говорят с EJB 3.0 все лучше стало, т.к. изучили опыт аналогов (читай стараются догнать). Но это немного поздно, и с учетом инертности крупных разработчиков все совсем плохо.

Все это рассчитывалось на то что с этим сможет работать совершенно некомпетентный специалист, который возьмет какую либо GUI рисовалку и, не понимая базовых принципов, наклепает работающее приложение. В результате совершенно непонятно как вся эта хренотень может работать, и требует огромных компьютерных ресурсов. Хотя для последнего всегда проще купить HP Superdome и не парится (к тому же часто наоборот, сервера уже стоят, а загружены на 10%, но это уже решается другими методами). На самом деле я даже согласен, часто действительно лучше и гораздо дешевле поставить железо мощнее, но только когда это не вызвано уродством архитектуры. Т.е. когда мы пишем сервер на Ruby (например) и получаем красивое технологически решение, поддерживаемое и легко расширяемое, то потребность в больших ресурсах вполне себе оправдана, но когда говорят «а нафиг нам пул соединений с БД? без него точно все работает, а с ним вдруг что случится? у нас сервер хороший и без пула потянет!» то тут уже не сервер ставить, а архитектора увольнять. Хотя и мысль теоретически даже правильная, но не в том месте.

JSF больше страдает клиентской избыточностью, но для intranet на это еще можно забить. Я даже пару раз пытался использовать это, но так и не понял вкуса. К тому же если нужно создавать хороший интерфейс не заморачиваясь с html/javascript, то надо использовать GWT, а не JSF. Но это, конечно, если нет в требованиях пункта «поддержка Netscape Navigator 3.0″, что еще было обязательным года 3 назад, надеюсь сейчас эти «компьютеры» уже окончательно доломались и на замену поставили те где можно поставить браузер посовременней.

А то к чему приводит разработка лишь на JSF могу проиллюстрировать тем что на очередном собеседовании с большим недоверием отнеслись к тому что я могу редактировать JSP/HTML в текстовом редакторе, вместо положенного WYSIWYG редактора. Очень удивились тому что я могу предполагать как изменится внешний вид в браузере после редактирования исходного HTML этой страницы. Я по своей наивности считал это вполне обыденной вещью, которую можно поручать даже школьнику-верстальщику. Ладно хоть не сказал что, к примеру, еще понимаю как HTTP протокол организован и на сайты хоть телнетом ходить могу.

Та вот, к чему я. В начале заголовок статьи был «Я не использую EJB и JSF», сейчас заменил на «Я не знаю EJB и JSF». Т.е. это скорее не принципиальное решение, а ситуация. Ведь может быть действительно моя проблема в том что я не знаю их? Может там есть очень серьезные плюсы? Серьезные выигрыши для проекта, для архитектуры, по сравнению с теми же Spring, Hibernate и пр.? Снижение каких то рисков? Если в случае EJB еще более-менее понятно, само по себе оно нужно, как минимум все части по отдельности востребованы. Вопрос в том нужны ли столь тяжеловесные решения иногда для простых задач, когда есть прекрасные и удобные альтернативы. Иногда конечно стоит взять готовую коробку от IBM, Oracle или BEA, вместо набора различных OS кубиков типа Mule, ActiveMQ, JBoss, Hibernate, Spring и т.д. Это касается EJB, а вот в случае JSF мне вообще непонятно как оно до сих пор существует и кому это надо, неужели JSF дает что-то такое что разработка становится настолько дешевле?

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

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

Метафора «Design debt/Долг проектированию» объясняет эту ситуацию. Когда команда работает под давлением сроков, то в первую очередь приносится в жертву архитектура приложения. Это как брать кредит по высокий процент. Команда получает ускорение в краткосрочном периоде, но с этого момента все изменения становятся дороже, эти изменения как бы выплачивают проценты по кредиту. Единственный способ перестать платить этот высокий процент, это исправить первопричину и сделать то что не было сделано когда решили отказаться от качественного дизайна.

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

Можно нарушить эту цепь, но это требует достаточно больших усилий. Начать нужно с того чтобы команда поняла что «кредит проектированию» неприменим в текущем проекте. Также всех нужно научить методам постепенного дизайна, рефакторинга, и пр. методам улучшения качества кода. Ну и, конечно, нужно выделить время на применения этих методов.

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

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

Иногда сложно увидеть долг проектированию, но если вы встретите нижеуказанные проблемы, то вы уже увязли:

• Команда отзывается о программе с упоминанием оборотов «куча заплаток», «хак», «работает и не трогай», «кто это понаписал!» и т.д.
• Команда часто сталкивается с неожиданными проблемами.
• После каждого исправления появляется череда новых ошибок.
• Ошибки которые уже исправляли появляются снова, через некоторое время.

Чтобы не залезть глубоко в долги старайтесь больше внимания уделять следующему:

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

На основе:
«Design Debt«, Software Profitability, February 2004, by Jim Shore

Поэтому проведем экперимент, сравним алгоритм по умолчанию, и пару считающихся лучшими алгоритмов. Выберем, так сказать, the best of the best среди хэширования Конкретно для меня, это равная вероятность состояний отдельных бит, в 32х битном целом. Т.е. чем ближе вероятность появления «1″ в каждой из позиций к вероятности 1/2 тем лучше.

И так, помимо алгоритма по умолчанию решил попробовать SDBM:

public int hash(String val) {
    int hash = 0;
    for (char c: val.toCharArray()) {
	hash = c + (hash << 6) + (hash << 16) - hash;
    }
    return hash;
}

и DJB2:

public int hash(String val) {
    int hash = 0;
    for (char c: val.toCharArray()) {
	hash = ((hash << 5) + hash) + c;
    }
    return hash;
}

и подсчитал отклонение от середины для случайно сгенеренных слов (как коротких так и длинных), на английском, русском, смешанном, смешанном+случайный регистр.

И вот график среднего отклонения, по этим четырем тестам:

По оси X - номер бита, по Y отклонение от равномерного, среднее для 4х тестов.
Видно что алгоритм по умолчанию, что DJB2 нормально работают лишь для первых 15 бит, дальше отклонения все больше и больше (на практике понижается вероятность заполнения бита по мере удаления от начала) В Java же int является 32х битным, поэтому в таком случае лучше использовать SDBM, который гораздо меньше отклоняется.

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

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

PS: это для моих потребностей важна именно равномерность, не буду утверждать что для всех остальных случаев SDBM алгоритм лучше/быстрее/пр., но вероятно что именно так.

sdx:"bfpvcgjkqsxzdtlmnr"!(4#1),(8#2),(3 3 4 5 5 6)
nn:{d2:x where x > 0;r:d2 where d1:0w<>':d2}
soundex:{(x[0],(nn (sdx@1 _ x)),l:4#0)[til 4]}

угу, именно так… Похоже что клавиатуру протирали.
Теперь запускаем:

>soundex "hellomyfriends"
("h";4;5;1)

А оно работает даже!

На самом деле из меня пока еще никакой специалист по K, и в действительности саму функцию (т.е. последние 2 строки) наверняка можно переписать укоротив раза в 2-3, вообще для такой мелочи должно 1 строки кода хватать, так что мой пример нифига не лаконичен. Но идея думаю понятна. На Java тоже самое было бы гораздо длиннее, я приводить алгоритм soundex не буду, но можете посмотреть на другие сравнения синтаксиса Java и K

Честно говоря вся фишка языка K вовсе не в том что он такой компактный, а в Kdb+ и их совместных возможностях, но все же, я именно о синтаксисе. Для Java кода, при кодревью, я всегда помечал записи вида:

x += isEmpty(s) || isDigit(s) ? 1 : 2;

и требовал что то вроде:

if (isEmpty(s) || isDigit(s)) {
    x++;
} else {
    x += 2;
}

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

Так вот для человека, который не знает программирования, а тем более уж Java и K, оба языка покажутся «китайской грамотой», и лишь для специалиста будет понятно, причем лишь тот пример на языке которого у него есть реальный опыт.

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

С другой стороны когда реализуешь алгоритм немного раздражает что пишешь сотни строк не относящихся напрямую к алгоритму (конечно постоянные Ctrl+Enter немного облегчают, но все же это не панацея), а после не можешь его окинуть взглядом и чтобы понять как оно работает появляются уродцы типа UML диаграмм. Ну и вообще пока описываешь эти бесконечные иерархии начинаешь забывать что собственно пишешь. Кстати, а может устроить программирование как в шахматных партиях: 8 машинисток и идти вдоль ряда, лишь парой фраз указывая каждой что ей нужно писать? В случае Kdb+/K ходит история что некоторые, совсем уж хакеры, на ходу, собственно в процессе получения ТЗ от зрителей, за 1-1,5 часа пишут небольшую ERP.

Так вот, к чему я, если отвлечься от «java разработчика без проблем найти, а под K замучаешься», то возникает вопрос: а все же как лучше? С одной стороны простота, с другой скорость реализации. Весь этот синтаксический overhead уже заставляет java разработчиков искать себя в ruby, python, groovy. Этакая золотая середина?

1. Используйте атрибуты для одной группы

Выносите короткие значения из одной группы в атрибуты.
Лучше

<user name="John" sname="Smith"/>

чем

<user>
 <name>John</name>
 <sname>Smith</sname>
</user>

2. Используйте CamelCase

Лучше всего lowerCamelCase, хотя достаточно распространен вариант с UpperCamelCase для элементов и lowerCamelCase для атрибутов.

3. Не используйте разделители

Это конечно входит в совет по CamelCase, но скажу отдельно: не надо разделять слова с помощью тире или подчеркивания.
Вместо

<user_name>foo</user_name>

пишите

<userName>foo</userName>

4. Не используйте лишнюю нумерацию

Если подразумевается что у элемента будет всегда несколько детей, то не надо их описывать как child1, child2 и т.д., опишите как они есть их позиция и будет этим номером. Для XSLT проще проверить функцию position(), чем делать всякие хаки для перехвата таких элементов. В крайнем случае можно добавить атрибут и именем index/position/x/и т.д. Работать с таким документом гораздо проще.
Вместо

<user>
  <phone1>1234567890</phone1>
  <phone2>0123456789</phone2>

  <cell1>12</cell1>
  <cell3>927</cell3>
</user>

напишите

<user>
  <phone>1234567890</phone>
  <phone>0123456789</phone>

  <cell index="1">12</cell>
  <cell index="3">927</cell>
</user>

5. Не надо тематических префиксов/окончаний

Не нужно всех эти firstItem + secondItem, workPhone + homePhone и пр. Все также как и в предыдущем пункте, нужно вынести все это в атрибут, например type:

<client>
 <phone type="home">1234567890</phone>
 <phone type="work">0123456789</phone>
</client>

6. Опишите похожие структуры одинаковым элементом

Многие различные элементы можно сократить до одного универсального. К примеру если элементы имеет множество однотипных подэлементов «параметров», то можно сократить их до вида:

<property name="xxx">value</property>

или

<property name="xxx" value="value"/>

Т.е вместо:

<user>
 <src>1</src>
 <load>Y</load>
</user>

написать

<user>
<property name="src" value="1"/>
<property name="load" value="Y"/>
</user>

Не факт что получится сэкономить на объеме кода, даже наоборот, но обрабатывать опять же проще будет. В данном случае нужно выборочно подходить, в зависимости от назначения документа, от того как его обрабатывать. И не надо перегибать палку, а то таким образом весь документ можно описать, построчно.

И напоследок: напишите XSD/DTD

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