Это вторая часть из серии 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-отдел.

Предлагаю решение, как быстро и просто поставить на сервере легкий фронтэнд для отдачи картинок, css-файлов и прочей статики. С лета 2002 года я для данных целей использую 0W-httpd или ZeroWait httpd, как его часто называют в разных источниках (искать что-то о нем, помимо дистрибутива, лучше по второму названию).
Установить и настроить его достаточно просто (даже слишком просто):

В этой статье я опишу принципиальные различия Apache и Nginx, архитектуру фронтэнд-бэкэнд, установку Apache в качестве бэкэнда и Nginx в качестве фронтэнда. А также опишу технологию, позволяющую ускорить работу веб-сервера: gzip_static+yuicompressor.

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

К примеру аренда четырехядерного AMD Opteron 2344 HE (1.7 GHz), 4Gb RAM, 2x250GB HDD обойдется в $100, что сравнимо с арендой порта и места в стойке под сервер у нас в стране.

В прошлом году Google в рамках своих инициатив по ускорению веб проектов представила свой инструмент для разработчиков Page Speed. Теперь же для упрощения труда разработчиков и вебмастеров Google предлагает нам новый инструмент.

Сегодня Google представила новый модуль для Apache под названием mod_pagespeed. По словам разработчиков время загрузки страницы удалось уменьшить на 50 процентов, а на отдельных проектах эта цифра значительно выше.

Сравнительная демонстрация с включенным модулем и без него



Ссылка для скачивания

UPD

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

В этой статье будет описано архитектурное решение низкого уровня облачной платформы Hivext, а именно уровня дата центров и взаимодействия между собой серверов разного типа.
Напомним, что проект Hivext — предназначен для более эффективного использования ресурсов (временных и финансовых) при разработке “богатых” интернет приложений (Rich Internet Application) и предоставляет широкий набор готовых взаимосвязанных сервисов.
Благодаря компании IT-GRAD мы получили возможность бесплатного разворачивания дополнительной копии платформы в Питерском дата центре (ДЦ). Нам выделили виртуальный хостинг на базе VMware vSphere 4. Работать с таким хостингом можно и через веб интерфейс и через десктоп клиент, все довольно удобно.

На данный момент Hivext развернута в 3-х территориально разнесенных ДЦ: Киев (Украина), Житомир (Украина) и Санкт-Петербург (Россия). Конфигурация платформы внутри каждого ДЦ построена по определенной структуре.

Предлагаю, так сказать, заглянуть под капот нашей платформы.

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

Маленькие проекты позволяют получить высокую доходность при низкой себестоимости. Масштабирование доходов решается путем привлечения новых работников. Форс-мажоры не особо влияют на благосостояние компании. Самое главное, что это быстрые деньги. Звучит очень привлекательно!

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

Топик навеян впечатлениями от докладов на swpiter и постом о том, как не продать машину :)

Как работать над стартапом и всегда оставаться в выигрыше?

Суть в чём, есть некая порция работы, которую нужно сделать перед тем, как начинать тратить свои деньги. Я попытался описать последовательность этих действий.

Картинка слева кликабельна, а ниже — текстовое описание в 12 шагах как инициировать стартап и при этом всегда оставаться в выигрыше.

1. Идея!

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

Самое важное в идее — это не терять мотивацию вплоть до 10 шага и тогда вы в любом случае получите для себя выгоду.

2. Детализация идеи

Необходимо хотя бы примерно ответить на эти вопросы:

• область применения
• какие задачи поможет решить
• какие инструменты применяются для решения задач
• что вы хотите получить в процессе и в результате реализации
• какие-то существенные моменты, которые вам просто необходимо изложить, чтобы не потерять в будущем

На этом этапе ещё рано отвечать на вопросы:

• сколько времени вы можете уделить (если идея вас реально интересует, вы перейдёте к следующим этапам)
• сколько на это нужно денег
• кто вам ещё нужен для реализации идеи

QooxDoo — достаточно хорошо проработанная JS-библиотека для разработки RIA (Rich Internet Applications). Углубляться в подробности библиотеки и описывать, откуда растут ноги проблемы не буду. Кто столкнулся с проблемой — тот поймет что к чему.
И так. Проблема заключается в том, что source-версия приложения, в том виде в котором ее собирает компилятор, не запускается с вебсервера (эмулирует denwer) а только как локальный файл.

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

В догонку к посту про макет бизнес модели, не менее полезный «самый короткий в мире маркетинговый план» (так его назвал автор, Келли Одел).

Можно для любой новой идеи, продукта или услуги заполнить эту табличку и сразу увидеть общую картину с перспективами.

Прекрасная тридцатиминутная история (на английском) от Джеймса Голика — CTO американской бдсм-соцсети выдерживающей 180 000 000 реквестов в месяц, при среднем времени отдачи ~200 мс, имея шесть серверов. В двух словах — смотрите тэги.

Введение

Все началось с того, что я стал системным администратором у одного провинциального Интернет-провайдера. Помимо администрирования различного рода ресурсов, мне в присмотр достался один молодой, но бурно развивающийся ресурс. Ресурс представлял из себя классический LAMP проект. Сайт, на котором генераторами контента являлись обычные пользователи.
* К слову, в то время я ничего не понимал в *nix системах, хоть и все сервера которые мне достались, были именно на нем, разбирался я во всем этом достаточно быстро.

Как обычно бывает с ресурсами, набирающими популярность, железки на которых все крутится, перестают справляться. Ресурс стоял на стареньком двухпроцессорном сервере, на котором крутились практически все сервисы для пользователей. В то время начальство не воспринимало ресурс как нечто стоящее вложений, поэтому, к моему сожалению (а позже – счастью), денег под новую железку мне не выделяли.

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

Итак, первое:

В рамках конференции Highload++, которая пройдет 25-го и 26-го октября в Москве, в конференц-центре «ИнфоПространство», мы в Оверсане придумали конкурс.

Highload++ проходит уже в четвертый раз, это место, где встречаются разработчики и администраторы высоконагруженных систем. Мы решили добавить в нее немного практики. HighLoad Battle — соревнование по быстрой разработке несложного, но устойчивого к нагрузкам проекта. Оценивать проекты мы будем по целому ряду как инженерных, так и экономических показателей. Для победителя мы приготовили хороший подарок — Apple iPad WiFi 64Gb, а для занявших второе и третье призовые места — запас ресурсов облачной инфраструктуры Скалакси.

Хочу Вам рассказать о штуке, которую я изобрел сегодня, чтобы ускорить процесс загрузки сайтов. Все вы знаете, что <script src="..."></script> задерживает отрисовку страницы, пока не загрузится этот скрипт. Если их десятки — это может сереьезно замедлить работу сайта — в результате пользователь 20 секунд пялится на пустую (или недорисованную) страницу из-за какого-нибудь тупящего социального виджета (умножить на десяток этих виджетов).

Не правда ли было бы круто, если бы можно было сказать <script extsrc="..."></script> ("extsrc" = "грузи потом"), чтобы скрипты загружались после того как страница отрисована?

Все бы хорошо, но есть document.write… Сегодня я наконец решил его проблему — представляю extsrc.js — скрипт, который запустит все скрипты после отрисовки страницы (даже если они содержат document.write — и правильно отрисуется все).

Результат? Супер-быстрая загрузка страниц, даже если там море всяких внешних скриптов.

Использование:

Заменяем <script src="..."> на <script extsrc="...">.

Итого получается:

<script src="http://whiteposts.com/extsrc_js/extsrc.js"></script>
<script extsrc="..."></script>

Заметка для тех, кто не специалист в NGINX, а проблему нужно решить быстро.

Допустим, у вас на сервере стоит NGINX и вы хотите, чтобы вся статика кешировалась у клиента. В конфиге хоста NGINX пропишите это:

server {
listen 80;
server_name mysite.com;
...
# Задаем правила обработки статического контента (типов файлов можно поставить и больше)
location ~* ^.+\.(jpg|jpeg|gif|png|ico|css|pdf|ppt|txt|bmp|rtf|js)$ {
root /path/to/document/root/; # Путь к корню вашего сайта
access_log off; # не пишем логи
expires 3d; # кешируем у клиента на 3 дня
}
}

Проверить можно в FireBug во вкладке NET: обновите страницу 2 раза и посмотрите код ответа. Если 200 ОК, то не работает. Если 304 Not Modified, то работает.

Неплохо ускоряет работу сайта.

Накопилось несколько маленьких заметок/советов про python и django, которые на отдельные топики не тянут, поэтому публикую все сразу.

Под катом:

• как упростить код вьюх ровно в 2 раза
• легкий способ рисования графиков
• почему Ian Bicking воскликнул «Cool!»
• приложения для ВКонтакте на django за 5 минут
• хорош ли pymorphy?
• пара фишек насчет выкладки пакетов на pypi
• что общего между декораторами и with-контекст-менеджерами
• принимаем оплату на django-сайтах
• показываем Яндекс.Карту для заданного адреса

Решая упражнения к книге «Программируем коллективный разум», я решил поделиться реализацией одного из алгоритмов упомянутого в этой книге (Глава 2 — Упражнение 1).

Исходные условия следующие: пусть мы имеем словарь с оценками критиков:

critics={'Lisa Rose': {'Superman Returns': 3.5, 'You, Me and Dupree': 2.5, 'The Night Listener': 3.0}, 
           'Gene Seymour': {'Superman Returns': 5.0, 'The Night Listener': 3.5, 'You, Me and Dupree': 3.5}}

Чем выше оценка, тем больше нравится фильм.
Надо вычислить: насколько схожи интересы критиков для того, например, чтобы можно было на основе оценок одного рекомендовать фильмы другому?