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

Чаще всего в целях экономии сервер устанавливался и как роутер для офисной сети и как сервер для хостинга веб-страниц. Следующим шагом было установка выделенного сервера у провайдера. Да, прямо вот железки, берем в руки и несем в датацентр. Подключаем и дебажим. Не дай бог какие-то проблемы с жестким диском. Алерты на софтварный рейд (аппаратный был слишком элитным и дорогим) были редкостью.

Все сервера тогда администрировались вручную, никакого особо Infrastructure as a Code не просматривалось. Нужно было поднять FTP, Apache, дать права на каталоги чтобы пользователи не видели друг друга. Создать типовую структуру каталогов, типа html, logs, etc. Создать правильные .htaccess с настройками для PHP и других языков. PHP и Parser не умели работать в виде daemon, поэтому хорошей практикой было загружать бинарник прямо в каталог и прописывать его как обработчик в .htaccess. Сейчас любой бы с точки зрения безопасности покрутил бы пальцем у виска.

Ах да, бэкапы. Какие бэкапы? Их скорее не было чем было. Если руки доходили, то один веб-сервер бекапил на другой веб-сервер. 

Все сильно поменялось с появлением клауда. AWS был еще долго неприбыльным направлением, однако со временем все поменялось, и владение собственным железом уже перестало быть мейнстримом. 

Не секрет, что продукты, разработанные на Ruby on Rails представляют собой жесть при установке. Разные версии ruby, разные версии конфликтующих gem и все такое делают жизнь тяжелее и грустнее.

 Пока не появился docker. Docker это чудо. Это Git для файловой системы.При помощи Docker установка gitlab или redmine становится почти тривиальной. 

Я попробую объяснить что такое Docker "на пальцах". Во-первых проще всего понять docker если рассматривать его как эдакую виртуализацию. Во-вторых docker имеет инструментарий для связывания одного виртуального окружения с другими окружениями. В-третьих это реализация концепции "одна роль – один сервер". В случае докера замените сервер на "контейнер" и получим "одна роль – один контейнер". Что круто само по себе и имеет ряд интересных эффектов. Один из таких эффектов это возможность передавать на тестирование, в продакшен или еще куда наше веб-приложение, которое уже установлено и гарантированно работает так же как и у разработчика. 

Вот несколько концепций, которые вам помогут понять, что такое docker.

1. Docker Image. Образ файловой системы, ее слепок с необходимыми библиотеками и софтом. Скажем, окружение веб-сервера. Вы можете создавать образы самостоятельно или загружать уже готовые, такие как gitlab или redmine.

2. Docker container. Используя образ файловой системы запущенный в памяти (или лежащий незапущенный на диске) производный образ от docker image. Допустим, запущенный веб-сервер.

3. Volume. "Расшаренная папка" между контейнером и хостовой файловой системой.

4. Port. "Проброс портов" или когда сетевой порт хостовой машины соответствует порту контейнера.

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

Ниже я опишу установку такой специфичной штуки как gitlab. С docker это сделать очень просто. 

 Самый простой способ установки нескольких контейнеров через docker-compose, который читает конфигурацию контейнеров из docker-compose.yml и делает их сборку и запуск автоматически. На самом деле это просто способ меньше руками писать ключей в строку консоли для запуска docker.

Вот пример запуска gitlab в две строки!

wget https://raw.githubusercontent.com/sameersbn/docker-gitlab/master/docker-compose.yml

docker-compose up

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

Я использовал в своей работе и Vim  и Emacs. В каждом из них есть свои плюсы и свои минусы. Об этом и хотелось бы сегодня поговорить. Многие вещи в этих редакторах реализованы одинаково хорошо: поддержка подсветки синтаксиса, сниппеты, командный режим, все то, что делает редактирование текста более эффективным, по сравнению с другими редакторами.

Сконцентрируемся на практических отличиях этих систем.

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

Emacs же чертовски неэргоромичен из коробки. Простая операция открытия файла ctrl-x + ctrl-f при дефолтном расположении ctrl заставляет в неестественной позе раскорячивать пальцы. Как workaround, большинство джигитов меняют caps lock и ctrl местами, за счет чего раскорячивание пальцев становится менее болезненным. Самые хардкорные пользователи emacs пользуют педали для нажатия ctrl и meta. Такая неэргономичность даже заставила некоторых выпустить т.н. эргономичный emacs http://ergoemacs.org/ в котором клавиши набиндили более человеколюбивым способом. 

При всем этом emacs очень расширяем, в первую очередь за счет Lisp, который компилируется буквально в realtime http://www.youtube.com/watch?v=GvQns1ULOtc . А это дает невиданные возможности расширяемости. Именно поэтому для Emacs есть и почтовый клиент, и twitter и jabber клиент и клиент для всего, что может пригодится в быту программиста.

И некоторые лица даже научились из emacs мастерить больше чем IDE http://emacsrocks.com 

Так что редакция nexus.org.ua рекомендует emacs всем тем, кто собирается напрограммировать на Lisp из emacs редактор своей мечты с блекджеком и твиттером, и Vim всем остальным казуалам, которые хотят быть эффективными в работе с текстом и при этом беречь руки от туннельного синдрома. 

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

http://habrahabr.ru/blogs/infosecurity/70330/

Быстрый способ излечения: 

find . -name ".svn" -exec rm -rf {} \;   

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

Фотошоп CS, Far , mysql, xselerator, topstyle, CVS, Apache (Denver) и главное, главное - Parser 3!

Что сейчас?

А сейчас emacs, SQLite, git и RoR. Ну и побочные вещи, типа RSpec, Cucumber, плагины, джемы.

За три с половиной года поменялось все: начиная c ОC, основного редактора и заканчивая языком программирования.Поменялся полностью подход к веб-разработке, способ мышления, стиль написания.

Теперь вместо "лапши" используется BDD подход к разработке.  Вместо Windows - Ubuntu. Вместо MySQL - SQLite. Вместо Far, xselerator, topstyle - vim, затем emacs. Вместо cp1251 - utf-8. Вместо CVS - SVN, затем Git. Вместо высокотехнологичных xslt шаблонов - обычные rails layouts. Вместо Nokia 6100 - IPhone 3G. Раньше не писал документацию к сайтам - теперь пишу.

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

Попробую пояснить термины приведенные выше.

Scrum - методология разработки основанная на agile. Если в двух словах вся разработка делится на Истории (Функционал), созданные совместно командой разработчиков и заказчиком. Заказчик излагает требования по функционалу, например, хочу редактировать статьи. Разработчики пишут три сценария для такого функционала: добавление, изменение и удаление статьи.

Каждая история получает очки по скорости разработки, например, добавление и изменение по 10 очков, а удаление статьи 5 очков. Добавляем параметр важности. Например, важность добавления - 5, важность изменения 10 и важность удаления 15.

Производительность команды измеряется в очках/период разработки. Например, принимаем производительность команды за период 3 недели (эти три недели будут называться Спринт) в 15 очков. Отсюда видно, что заказчик может или потребовать реализацию удаления и изменения за один Спринт, или реализацию удаления и добавления повысив важность фичи добавления.

А в следующий Спринт будет добавлен недостающий функционал, например, добавления статьи. 

Обязательным моментом в описании Сценариев является описание методики тестирования, например, нажми туда, смотри здесь и получишь это. 

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

Свежепоявившийся Cucumber позволяет в почти такой же манере scrum описывать функционал со сценариями и ... проводить тестирование rails приложения иногда называемое интеграционными тестами.

Для тестирования в Cucumber может использоваться как библиотека Webrat, по сути рендерит выдачу HTML эмулируя браузер, и позволяет такие вещи, как заполнить поле формы, нажать на кнопку,открыть ссылку прямо в коде ruby и получить результат, который будет  сравнен с ожидаемым. Типично - заполнить пароль и логин в форме, и сравнить, есть ли в выдаче сообщение "добро пожаловать _пользователь_". При еще более глубоком погружении есть возможность использовать Selenium - фреймворк для тестирования прямо через вызовы браузера и использования его DOM, т.е. натурально, запускается фаерфокс, и через его DOM производится тестирование вывода страницы. Что вообще говоря позволяет вовсю тестировать Ajax плагины, работу Prototype и jQuery, что, если не ошибаюсь, Webrat  делать не умеет.

Следует заметить, что Cucumber  это верхний уровень абстракции тестирования который заменяет традиционные интеграционные тесты, для тестов на нижнем уровне все равно прийдется использовать Test::Unit или RSpec, выбор за вами.

Очень подробно тематика освещена здесь.

Как всегда, хит сезона - кодировки php и mysql на хостингах.

Пока программисты не поймут, что utf-8 это хорошо, системным администраторам ничено не остается как лечить связки php cp1251<->mysql utf-8 и прочие дивные вещи.

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

if (mysql_query("SET NAMES 'UTF8'") === false) return false;

в скриптах сразу после коннекта к базе.

Сейчас стало модным стряхивать пыль с древних true редакторов, таких как Vi и Emacs.

Да чего уж, один проект на RoR сделал сидя за Vim, еще пару на Emacs.

А вот тут люди пишут, как правильно готовить Emacs:

http://technomancy.us/115

http://nubyonrails.com/articles/emacs-emacs

http://peepcode.com/

Но при всем моем уважении к Emacs, есть у него существенные огрехи:

1. Напрочь отстуствует интуитивно понятная система пакаджей для модулей (плагинов), все зависимости гоу-гоу ручками.
2. Иногда проявляются странные проблемы с перерисовкой экрана (text overlapping)
3. Он стар, очень стар, супер стар! Поэтому исходники в CVS
4. Truetype шрифты в emacs до сих пор (!) являются проблемой. При чем под windows этой проблемы нет :(
5. shell mode не совсем корректен
6. Пробовали gnus или другую обработку почты? А я пробовал. Грустно это.
7. И elisp я б выучил только за то, что на нем разговаривал Ленин (Столлман).