Предлагаю перевод хорошей статьи с советами по выполнению фиксаций в хранилище. Оригинал написан для проекта T2, но практически все советы универсальны и легко применимы для любого другого проекта. А самое главное — они действительно полезны.
Upd: В названии статьи хоть и фигурирует SVN, но советы, изложенные в ней, подходят ко всем известным мне системам кондроля версий. Стоит так же заметить, что советы направлены в основном на командную разработку.
Кто-то скажет: незрелость — производство ПО еще молодая промышленность и все эти изменения — путь к некоторым истинным основам. Другие говорят, это потому, что люди от программирования просто любят выдумывать всякие штуки и сами не могут разобраться. А я скажу так: раз уж мы идем к тому, чтобы иметь дюжины моделей, хотя бы некоторые из них могут быть честными, хотя и циничными, по отношению к тому, что на самом деле происходит большую часть времени.
С репликацией серверов MySQL я познакомился относительно недавно, и по мере проведения разных опытов с настройкой, записывал, что у меня получалось. Когда материала набралось достаточно много, появилась идея написать эту статью. Я постарался собрать советы и решения по некоторым самым основным вопросам, с которыми я столкнулся. По ходу дела я буду давать ссылки на документацию и другие источники. Не могу претендовать на полноту описания, но надеюсь, что статья будет полезной.
Недавно мне пришлось столкнуться с необходимостью разработать собственный небольшой модуль для веб-сервера Apache 2.2.x. Проведя несколько часов в поисках подходящей информации, я столкнулся с тем фактом, что по-русски об этом мало кто рассказывает. Поэтому и возникла идея написать эту статью. Ниже я постараюсь как можно подробнее поделиться накопленным опытом, пошагово описать этапы создания модуля и приведу различные полезные ссылки по данной теме.
Пообещал вчера написать статью о реальных случаях оптимизации БД MySQL.
Пришлось сегодня вставать утром пораньше чтобы воплотить обещанное в жизнь.
Централизованное управление мыслями поддерживать еще сложно, поэтому не судите строго за казусы и ляпсусы в моей статье.
В последнее время приходится достаточно часто заниматься оптимизацией производительности сайтов. И как правило «бутылочным горлышком» в производительности работы этих сайтов является именно БД, ошибки как в архитектуре так и в выполнении запросов. Начиная от неправильной расстановки индексов, либо совершенным их отсутствием, неправильным (неэкономным) выбором типов данных под определенное поле, заканчивая абсолютно нелогичной архитектурой БД и такими же нелогичными запросами.
В данной статье опишу несколько приемов, которые были использованы для приложения с 4млн+ пользователей и которое имея порядка 100млн+ хитов в сутки, а в конце опишу задачу, которая решалась недавно и может быть многоуважаемое сообщество предложит мне решения этой задачи более эффективное нежели то, к которому пришел я.