Привет!

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

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

Итак, для версионирования, в бакете нам прежде всего нужно его включить. Есть 2 доступных способа это сделать, и оба они завязаны на API.

• Чистый REST/SOAP запрос
• Через библиотеку

Я воспользуюсь Ruby библиотекой aws-sdk, которую и установим:

$ gem install aws-sdk

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

Способов хостинга mercurial репозиториев достаточно, но я сочинил именно такой вариант по следующим причинам:

1. nginx: мало кушает, быстро работает — скорость
2. supervisor: мониторит процесс, перезапускает если что — надёжность
3. gunicorn: wsgi, большие возможности по настройке — эффективность

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

Если вас заинтересовала тема, то конкретные инструкции и конфиги — под катом.

При клонировании репозитория с помощью команды

hg clone A B

mercurial сначала пытается создать жесткие ссылки для файлов внутри папки .hg в новом репозитории. Это ускоряет клонирование и экономит место на жестком диске.

Жесткие ссылки поддерживаются файловыми системами Linux и Windows NTFS. Для файловых систем, которые не поддерживают жесткие ссылки (например Windows FAT), а также при клонирование через http/https или ssh с удаленного сервера mercurial полностью копирует все файлы.

Несколько дней назад передо мной поставили задание — поднять mercurial-репозиторий на одной из локальных машин, и поставили одно условие — обязательная авторизация по SSH. Установка будет производится с использованием Mercurial Server на 64-битной серверной Убунте.

Это шестая, заключительная часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:

• «Переобучение для пользователей Subversion»
• «Основы Mercurial»
• «Привыкаем работать в команде»
• «Исправляем ошибки»
• «Процесс слияния»

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

Часть 6. Архитектура репозиториев

Наш рецепт становится все лучше:

Это пятая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:

• «Переобучение для пользователей Subversion»
• «Основы Mercurial»
• «Привыкаем работать в команде»
• «Исправляем ошибки»

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

Часть 5. Процесс слияния

Обеспечение слаженной работы нескольких людей над одним и тем же кодом — это важная функция системы контроля версий.

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

Это четвертая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:

• «Переобучение для пользователей Subversion»
• «Основы Mercurial»
• «Привыкаем работать в команде»

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

Часть 4. Исправляем ошибки

Mercurial позволяет свободно экспериментировать. Представьте, что во время работы вы что-то не то сделали в редакторе, и случилось нечто ужасное:

Это третья часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Предыдущие части:

• «Переобучение для пользователей Subversion»
• «Основы Mercurial»

Одно из преимуществ использования Mercurial — возможность работать командой над одним кодом. Mercurial позволяет каждому работать независимо и помогает объединять сделанные изменения.

Часть 3. Привыкаем работать в команде

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

Это вторая часть из серии Hg Init: Учебное пособие по Mercurial от Джоэля Спольски (Joel Spolsky). Возможно, вы захотите прочитать и первую часть «Переобучение для пользователей Subversion».

Даже если вы работаете в одиночку, то вам стоит использовать Mercurial. Так вы сможете получить все прелести контроля версий. Эта часть покажет насколько просто добавить каталог в Mercurial, чтобы с легкостью отслеживать предыдущие версии.

Часть 2. Основы Mercurial

Mercurial — это система контроля версий. Разработчики используют ее для администрирования исходного кода. У нее два основных назначения:

1. Она хранит все предыдущие версии каждого файла
2. Она может объединить разные версии вашего кода, то есть сотрудники могут независимо работать над кодом и затем объединять свои изменения

Hg Init: Учебное пособие по Mercurial.

Mercurial — это современная распределенная система контроля версий с открытым кодом. Эта система — заманчивая замена для более ранних систем вроде Subversion. В этом простом учебном пособии в шести частях Джоэль Спольски (Joel Spolsky) рассказывает о ключевых принципах Mercurial.

Если вы использовали Subversion, то Mercurial будет непонятным. Эта часть рассказывает о главных отличиях при работе с Mercurial. Если вы никогда не использовали Subversion, то можете просто пропустить эту часть.

Часть 1. Переобучение для пользователей Subversion

В каком же я был смятении, когда программисты в моей компании решили сменить Subversion на Mercurial!

Для начала, я начал приводить всевозможные тупые причины, по которым нам не надо ничего менять. «Мы должны хранить репозиторий на центральном сервере, так безопаснее», — сказал я. Знаете что? Я был неправ. При работе с Mercurial у каждого разработчика на жестком диске хранится полная копия репозитория. Это, на самом деле, безопаснее. В любом случае, почти в каждой команде, использующей Mercurial, центральный репозиторий тоже существует. И вы можете делать резервное копирование этого репозитория со всей необходимой одержимостью. А еще можете устроить трехступенчатую защиту с Сайлонами, Штурмовиками и прелестными лабрадудлами или что там требует ваш IT-отдел.

Введение

Встречаются предприятия, на которых доступ к интернету сильно ограничен или не постоянен, не завидую этим ребятам. Иногда, как в моём случае, политика безопасности предприятия не позволяет хранить исходный код разрабатываемых продуктов на чужом оборудовании. Кроме того, смею предположить, что не каждой группе разработчиков хватает возможностей, предоставляемых например bitbucket. Эти проблемы можно решить, к примеру, связкой RhodeCode и Redmine.

Цели

• Создание, изменение, удаление репозиториев Mercurial, используя web интерфейс.
• Добавление и удаление пользователей, разграничение доступа, смена паролей, используя web интерфейс.
• Отслеживание ошибок и распределение задач, используя web интерфейс.
• https повсеместно.

Вас могут смутить столь архаичный цифры в заголовке, однако, думаю, не я один до сих пор использую в работе w2k3 и mssql2000. Причина банальна: зачем что-то покупать, когда это куплено и работает. Дискуссию о недостатках/преимуществах w2k3 и w2008 предлагаю опустить. C другой стороны я не чужд прогрессу и в последнее время плотно использую в своей работе mercurial. И вот возникла необходимость поднять внутренний сервер, при этом в наличии имеется как раз таки оной из заголовка. Речь далее пойдет не о hg serve, а о полноценном hgweb. Статья возникла по причине того, что на то, чтобы заставить его работать, ушел целый день; при этом пошаговые инструкций на русском найдены не были. Да и английских не пруд пруди.

Введение и отмазка

Доброго времени утра,

Возможно, всё о чём я сейчас буду рассказывать делается проще, правильнее, уже сделано, придумали ещё австралопитеки. Возможно это даже будет воспринято как издевательство над всем упомянутым, а вы зря потратите несколько минут своего драгоценного времени. Знайте — я предупреждал!

Если ещё не закрыли статью — обрисую ситуацию:

Что у нас есть

У нас есть nginx, mercurial несколько самостоятельных проектов, на каждый из которых имеется 3-4 репозитория. Ещё у нас иногда могут появляться сторонние разработчики, которым часть этих проектов показывать совершенно не обязательно.

Что со всем этим делать?

hg review — полезная плюшка для mercurial'а

У git'а есть GitHub, а у Mercurial'а есть hg review. На самом деле я сравнил козу с бояном.

Ревью кода.

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

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

Сейчас всё больше мобильных приложений становятся геозависимыми. Одни просто не имеют смысла без знаний о местоположении пользователя, другие становятся с ним удобнее. Это так называемые Location Based Services (LBS): навигаторы, форскверы, инстаграмы с геотегами фотографий и даже приложения-напоминалки, которые срабатывают около конкретного места, например, рядом с офисом или магазином.

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


Технологию мы давно открыли в виде бесплатного API. Сегодня хотим рассказать, как она устроена.

Привет!

С сегодняшнего дня можно копировать EBS Snapshot'ы в другие регионы. Это отличная и удобная функция, которая позволяет клонировать ваши сервисы и данные в разные регионы родными способами!

В меню снапшотов появилась опция Copy Snapshot:

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

• вики, учет задач, тикетов, дефектов;
• система управления версиями/репозиторий;
• файловый сервер.

И если в случае первого и второго предлагается множество прекрасных средств, в частности для багтрекинга существуют известные каждому Redmine, Trac, а для управления версиями Subversion, Git, Mercurial, то для грамотной организации файлового хранилища приходится в очередной раз изобретать велосипед.

Этот алгоритм является улучшенным алгоритмом поиска пути A*. JPS ускоряет поиск пути, “перепрыгивая” многие места, которые должны быть просмотрены.  В отличие от подобных алгоритмов JPS не требует предварительной обработки и дополнительных затрат памяти. Данный алгоритм представлен в 2011 году, а в 2012 получил высокие отклики. Что из себя представляет данный алгоритм и его реализацию можно прочитать дальше в статье.

В последнее время все чаще приходится сталкиваться с неправильными мнением относительно использования Open Source на базе Windows Azure. Будь то вопросы на мероприятии, или обсуждение на форуме периодически возникают мифы о платформе Windows Azure, самые популярные, на мой взгляд, я развею: