Когда-то давным-давно на Земле был остров, на котором жили все духовные ценности.
Но однажды они заметили, как остров начал уходить под воду. Все ценности сели на свои корабли и уплыли.

На острове осталась лишь Любовь. Она ждала до последнего, но когда ждать уже стало нечего, она тоже захотела уплыть с острова. Тогда она позвала Богатство и попросилась к нему на корабль, но Богатство ответило:
– На моем корабле много драгоценностей и золота, для тебя здесь нет места.

Когда мимо проплывал корабль Грусти она попросилась к ней, но та ей ответила:
– Извини, Любовь, я настолько грустная, что мне надо всегда оставаться в одиночестве.

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

Паттерны проектирования

Википедия — там, в принципе, на хорошем уровне все описано и приведены примеры на разных языках.
Базовая книга – классика:
«Приемы объектно-ориентированного проектирования. Паттерны проектирования» — читал книгу давно, и раза 3. Вам того же советую. Даст возможность понимать большое количество терминов, произносимых другими разработчиками.

Рефакторинг

«Рефакторинг. Улучшение существующего кода» — вероятно, эта книга сделала революцию в написании кода. Читается быстро и интересно. Методы рефакторинга должны отложиться в голове до конца жизни. Ваш код отныне будет лучше. В книге есть упоминание про юнит тестинг.

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

В примерах будет использоваться Subversion, хотя все рекомендации полностью применимы к любой другой системе контроля версий.

Грубо разделим фазы разработки проекта на три — дебют, миттельшпиль и эндшпиль.

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

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

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

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

Прелюдия

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

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

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

В Rails есть полезная возможность assets timestamps, если честно, раньше не понимал зачем это нужно.

Разберёмся?

Практически все согласны, что бакапы делать надо. Но, тем не менее, эта проблема всплывает снова и снова. Недавний опрос продемонстрировал два любопытных момента: во-первых половина из нас бакапы не делает вообще, а во-вторых автору даже не пришло в голову включить в опрос пункт «раз в день». Что же не так с простой, на первый взгляд, задачей — запаковать свои файлы и положить архив в тёплое и сухое место?

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

С рассветом WEB 2.0 получили развитие и javascript фрэймворки, позволяющие вебмастеру делать динамические элементы сайта гораздо быстрее и проще. Одним из таких фреймворков является jQuery, получивший огромную популярность за свою простоту и невероятно малый вес. Итак, представляю вашему вниманию 10 наиболее полезных скриптов jQuery для улучшения интерфейса вашего сайта.

Наверное, многие из читающих «Linux для всех» пользуются SSH. Я, например, администрирую большое количество UNIX-систем, и, чтобы быстро получить доступ к нужной машине, приходится использовать возможности протокола на уровне, отличном от примитивного.

screenshot #1
screenshop #2

Введение

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

jQuery — это замечательный JavaScript Framework, который подкупает своей простотой в понимании и удобством в использовании. Но изучение надо с чего-то начинать, и лично моё мнение — лучше всего начинать с наглядных примеров, и они далее…

Сегодня мы научимся набирать в Vim загадочные и просто редко- (а кем-то часто-)используемые символы, такие как ½, ?, £, ©, ®, ™, «, » и т.д. Особенно полезно это людям, связанным с типографикой, но не только.

Для набора этих замечательных вещей есть много способов, некоторые из них уже были описаны на Хабре. Способы эти сводятся либо к установке специального ПО, либо к созданию собственной раскладки клавиатуры. Ещё можно (во всяком случае, под Windows) запоминать магические комбинации и набирать символы с помощью Alt+цифры_на_цифровой_клавиатуре_если_она_есть.

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

Уже были статьи про основы гита (0, 1, 2), были и статьи про внутреннее устройство репозитория. Сегодня поговорим, как простому смертному работать с гитом на автопилоте и не морочить себе голову.

Во-первых, шорткаты (в порядке убывания популярности):

alias gst='git-status'
alias ga='git-add'
alias gc='git-commit -m'
alias gp='git pull && git push'
alias gull='git pull'
alias gush='git push'
alias gb='git-branch'
alias gco='git-checkout'
alias gd='git-diff'

Во-вторых, отображение текущей ветки в командной строке:

export PS1='`__git_ps1 "%s"` \w \$ '

Выглядит так:

lazy-args-in-futures ~/Work/io/oleganza-io.git $

(Как установить: ericgoodwin.com/2008/4/10/auto-completion-with-git)

Типичный поток работы в одной ветке

«Чтобы стать экспертом в практической или научной области, нужны огромный труд и долгое время. Если человек добросовестно трудится каждый час рабочего дня, когда-нибудь он проснется одним из самых компетенткых специалистов своего поколения.»
Ульям Джеймс

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

Но ведь программы пишут люди, такие же, как мы с вами. Одни становятся выдающимися программистами и достигают больших успехов, другие же забрасывают профессию. Перефразируя классика, можно сказать: «покажи мне свой код, и я скажу, кто ты». Исследования показывают, что лучшие программисты создают программы в 10 раз быстрее, чем их менее квалифицированные коллеги. Время, уходящее на отладку кода, а также объем и быстродействие итоговой программы, уровень ошибок и число обнаруженных ошибок также различаются примерно в 10 раз.

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

Update: похоже, что после обновления хабра появились проблемы с постингом больших статей. Старый текст, который был здесь ранее, хабр обрезал до середины, залить же новый мне не удалось — все время выдается ошибка «Возникла ошибка в получении XML данных: Internal Server Error» (насколько я понял, проблемы именно в большом объеме). Честно говоря, у меня сейчас нет ни времени ни желания разбираться с этим (к тому же переформатирование статьи из блога под хабр занимает довольно много времени), поэтому отсылаю вас к оригиналу — Очередной HowTo по Vim.

Ниже перевод статьи «Optimizing Page Load Time», в которой автор математически рассчитывает оптимальный размер файлов для эффективной передачи при веб-запросах, рассматривает некоторые прикладные вопросы оптимизации загрузки страницы с учетом особенностей браузеров, а также дает несколько развернутых и ценных советов. Мои комментарии далее курсивом.

Существует распространенное мнение, что быстро загружающая страница положительно влияет на впечатление пользователя (improve the user experience). В последние годы многие сайты начали использовать для этой цели технологию AJAX, чтобы уменьшить время ожидания (при загрузке данных). Вместо того, что запрашивать с сервера новую страницу полностью при каждом клике, браузер часто можно либо поменять вид самой страницы (отобразив или скрыв какие-либо блоки), либо подгрузить небольшую порцию HTML-, XML- или JavaScript-кода и внести изменения на существующую страницу. В любом случае, это значительно уменьшает время, проходящее между кликом пользователя и окончанием визуализации браузером нового содержания.

Что влияет на загрузку страницы?

Однако, для большинства сайтов, загрузка страницы затрагивает десятки внешних объектов, основное время загрузки тратится на различные HTTP-запросы картинок, JavaScript-файлов и файлов стилей. AJAX, возможно, поможет в данной ситуации, но ускорение или удаление этих HTTP-запросов может принести гораздо больше пользы, хотя на данный момент нет единого мнения (a common body of knowledge), как именно это следует делать.

читать дальше на webo.in →

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

Основы масштабирования

Масштабируемость — способность устройства увеличивать свои
возможности
путем наращивания числа функциональных блоков,
выполняющих одни и
те же задачи.
Глоссарий.ru

Обычно о масштабировании начинают думать тогда, когда один
сервер не справляется с возложенной на него работой. С чем именно он не
справляется? Работа любого web-сервера по большому счету сводится к основному
занятию компьютеров — обработке данных. Ответ на HTTP (или любой другой) запрос
подразумевает проведение некоторых операций над некими данными. Соответственно,
у нас есть две основные сущности — это данные (характеризуемые своим объемом) и
вычисления (характеризуемые сложностью). Сервер может не справляться со своей
работой по причине большого объема данных (они могут физически не помещаться на
сервере), либо по причине большой вычислительной нагрузки. Речь здесь идет,
конечно, о суммарной нагрузке — сложность обработки одного запроса может быть
невелика, но большое их количество может «завалить» сервер.