Конфигурация сайта: конфигурация сервера

Продолжим, пожалуй, разговор про конфиги (часть 1, часть 2.1, часть 2.2).

На этот раз отвлечёмся от теории и перейдём к практике. Чтобы нам такое законфигурировать?

Законфигурируем, пожалуй, какую-нибудь конфигурацию :) Допустим, конфигурацию веб-сервера и пусть сервером этим будет Nginx.

Задача более конкретно:

  • Разрабатываем сайт example.ru
  • Я разрабатываю в своей локальной версии — go.example.local, а другой разработчик в своей — hugo.example.local + ещё верстальщик с дизайнером
  • Есть у нас общая локальная версия example.local на локальном сервере.
  • И есть тестовый поддомен test.example.ru, на котором заказчик проверяет последнии фишки, перед тем, как их зальют собственно на example.ru
  • test.example.ru находится в открытом доступе и его следует закрыть хотя бы с помощью htpasswd
  • Все загружаемые изображения лежат на поддомене «img.*», то есть img.example.ru, img.go.example.local и т.д.

Итак, у нас уже 7 версий сайта. Каждая на своём хосте. И для каждого хоста нужно иметь nginx-конфиг. Все конфиги имеют одинаковую структуру, но отличаются частностями.

Что мы будем их 7 раз копипастить и корректировать? А любое изменение в структуре вручную в каждую версию вносить? К чёрту! Давайте всё автоматизируем.
Остальной текст под катом

, , , ,

[без названия]

Или такой вот вопрос.

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

А в самом самолёте курить или вообще нельзя, или для этого отдельный салон, отгороженный от нормальных людей.

Интересует следующая вещь: почему курильщиков от остальных изолируют, а родителей с малолетними детьми нет? От них же вреда для здоровья окружающих несравнимо больше.

PHP 5.4 alpha

Итак, потрясшая весь мир радостная весть — вышла альфа PHP 5.4. Такими темпами есть надежда, что не пройдёт и десяти лет, как появится стабильный релиз.

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

Какие же прелести нас ожидают:

1. Traits: сколько бы задроты «чистого ООП» не гневались, а вещь в умелых и умеренных руках вполне себе полезная. Реализация опять может вызывать вопросы, но всё же лучше, чем ничего.

2. Array dereferencing: всего пяток лет обещаний и вот оно. Вот так вот уже было можно: func()->method(), вот так тоже: $A['var'], и даже так: $A['var'](). Теперь можно так: func()['var]. Ещё пара нововведений и пых обгонит питон по языковым плюшкам.

Единственно может напрягать тот факт, что обязательно найдётся большое количество индивидуумов, которые начнут делать следующее:

function get($id) {
    // Дикий запрос в базу
}
 
echo 'Имя: '.get(1)['name'];
echo 'Фамилия: '.get(1)['surname'];
echo 'Вся фигня: '.get(1)['fignya'];

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

3. Поддержка DTrace: несомненно отличнейшая вещь, которая сделает нашу жизнь намного лучше.
А может и не сделает. Я, если честно, вообще не знаю, что это такое.

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

4. Чистка мусора: register_globals, allow_call_time_pass_reference, register_long_arrays, session_is_regisitered(), session_registered(), session_unregister().

Давно пора, но единственно печалит удаление allow_call_time_pass_reference. Это, когда разрешается по старинке решать в момент вызова как передавать аргумент в функцию: по ссылке или по значению. Без включения этой настройки тоже разрешается, но интерпретатор начинает бурчать себе под нос про DEPRECATED.

Мне оно не нужно, но иногда приходится в чём то старом копаться. Что характерно, все остальные хреновены (register_globals, long_arrays) давно не встречаются. И в случае чего легко эмулируются. А time pass reference вылезает зачастую и так просто от него не избавишься.

, ,

Сисадмин (или помощник), СПб, 20 000 руб

Спасибо, вакансия закрыта

Так, а теперь нам нужен сисадмин.

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

Требования

  1. Unix, nginx, apache, php, mysql и всё сопутствующее с административной точки зрения
  2. DNS, DHCP и т.д. и т.п.
  3. Немного Windows
  4. PHP на уровне, чтобы хотя бы знать где поменять параметры подключения к базе при переносе
  5. …
  6. Ну вы поняли…

Примеры задач на начальном этапе

  1. Перенести сайт с виртуального хостинга к нам на сервер.
  2. Перенести ещё 30 сайтов с виртуального хостинга к нам на сервер.
  3. Сбегать за стремянкой и проверить почему не пингуется роутер спрятанный в потолочном перекрытии.
  4. Разобраться почему вдруг отвалился сайт.
  5. Ругаться с техподдержкой различных хостингов по телефону.
  6. Перетащить провода в офисе так, чтобы не мешались под ногами.
  7. Помочь девушке-менеджеру у которой завис комп.
  8. Сбегать в праздник за пивасом, если больше некому.
  9. Если что-то не получается, не бояться сказать об этом чётко, вместо того чтобы сидеть и тупить.

Карьерный рост

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

С нас

  1. Двадцать тысяч рублей в месяц в начале.
  2. Рабочее место на 40 часов в неделю, впрочем больше находиться на нём запрещать не будем.
  3. Балкон, выходящий на Таврический сад.
  4. Чай, кофе, сырные палочки, пицца.
  5. Молодой, разнополый коллектив.
  6. Дартс и другие безделушки для тех, кто сделал все дела на сегодня.
  7. Люди, готовые научить тому, что знают, если есть желание учиться.

Контакты

go@blgo.ru

goDB + PostgreSQL

А в это время goDB продолжает развиваться благодаря волонтёрам со всего мира.
Вот и Алексей Полев aka dallone запилил адаптер для Постгри.
Ура Далону!

,

Программисто-верстальщик, СПб от 20 000

Программист-верстальщик

[Закрыто].

А ещё нам нужен программист на PHP и JavaScript и по совместительству верстальщик на HTML.
Больше программист, но и немного верстальщик.
Которого мы будем грузить огромной кучей всякой неприятной работы.
Образование и пол не важны, большого опыта не требуется.

Знания:

  • PHP 5
  • JavaScript
  • MySQL
  • HTML, CSS

Умения:

  • Уметь программировать.
  • Уметь верстать.
  • Любить программировать и верстать.
  • Любить разбираться в чужом коде и вёрстке.
  • Терпимо относиться к чужому говнокоду и говновёрстке.

С нашей стороны:

  • Молодой дружный разнополый коллектив.
  • Амбициозная компания, один из лидеров бла-бла-бла.
  • От 20 000 рублей в месяц в начале.
  • Ещё больше рублей в месяц в зависимости от успехов.
  • Рабочее место на 40 часов в неделю.
  • Окна на Таврический сад.
  • Дартс и прочая фигня.
  • В случае желания расти выше, есть и интересные проекты и люди, которые помогут.
(Картинка скопипащена с securitylab.ru)

goDB: юбилейчик

Сегодня ровно 3 года, как я осмелился выложить свою поделку, предназначенную для работы с мускулем из PHP.

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

Что особо удивительно, её даже качают другие люди, несмотря на то, что «подобное было тыщу раз», «есть намного лучше» и «мне ты это дерьмо не втюхаешь». За прошлый год библиотечку скачали 1 597 раз с 992 уникальных IP. В прошедшем же январе за этим глупым занятием был застукан 121 уникальный айпишник. Вот график (толку в нём нет, просто для внесения разнообразия в унылый текст):

График скачиваний goDB за 2010 год

У библиотеки даже появился один почётный пользователь.

Если вас угораздило где-то использовать goDB, пожалуйста, не постесняйтесь кинуть мне адресок: я их соберу в одном месте. И мне понтов больше и вам ссылочка лишняя :)

Воскресный вечер брюзжания

spy

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

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

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

Остальной текст под катом

Конфигурация сайта 2.2: совместная разработка (наследование)

Продолжаем разговор из прошлых двух частей.
Конфигурация сайта 1: введение
Конфигурация сайта 2.1: совместная разработка (платформы)

В прошлой части у нас массив, соответствующий какой-то платформе (например, vasya), вливался в массив некой базовой конфигурации (config.php). Назовём это: «vasya наследуется от config».

Раньше я делал так:

config — конфигурация системы на рабочем сервере, от неё наследуются конфигурации разработчиков.

Оно не всегда удобно. Лучше наследоваться от какой-то базовой конфигурации, а рабочей сервер поставить в один ряд с разработчиками. Тем более в нашем примере рабочих серверов у нас несколько.

Наследуем всё от базового конфига и введём ещё промежуточные этапы:

Остальной текст под катом

, ,

Конфигурация сайта 2.1: совместная разработка (платформы)

В прошлой статье мы разобрались, как можно хранить конфигурацию системы и как её можно использовать.

Однако, мы подразумевали простейший вариант, когда система работает в единственной копии на сервере. Усложним положение:

Итак, бравые разработчики Вася, Петя, Миша и Гриша в поте лица разрабатывают очередную социальную сеть нового поколения. Каждый ведёт разработку в своей локальной версии на своём компьютере. Наработки они выкладывают на локальный тестовый сервер (где-нибудь в офисе в шкафу пылиться). Выкладывают, конечно, не по FTP, а с использованием какой-нибудь системы контроля версия, например, Mercurial.

Ведущий программист проверяет обновления на наличие ошибок и в случае чего даёт по шее. Если же ошибок не видно и локальная версия достигает какого-то стабильного состояния: все изменения отправляются уже на боевой сервер. Вернее на сервера, потому что проект крупный и серверов уже аж три штуки стоит.

Итого, система работает уже не в одной копии, а в восьми (4 разработчика, локальный сервер, 3 рабочих сервера). Назовём то, где работает конкретная копия системы платформой и дадим каждой имя (платформа server.1, платформа vasya, платформа local и т.д.).

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

Подумаем, как это можно организовать.

Остальной текст под катом

, ,
По страницам:← 123456789101112131415→