Слайды.

Презентация.

Слайды

Рассказ основан на некоторых общедоступных знаниях и личном опыте. Рассчитан как на начинающих, так и на опытных разработчиков.

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

Обсуждается путь запроса пользователя до и внутри сервера, его обработка и возврат ответа. Затрагиваются вопросы состояния приложения — работы с хранилищами, кэширования.

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

Смотрите в полноэкранном режиме.

Но, не смотря на такую расплывчатость вопроса, дать ответ на него все же можно. Можно описать примерный максимум знаний, которые так или иначе относятся к программированию. Собственно, этот максимум обычно и стремятся преподать в ВУЗах на специальностях, в названии которых фигурирует слово “программист”.

Я учился на программиста в колледже, потом в университете. Именно университет немного разложил по полочкам понимание и взаимосвязь дисциплин, относящиеся к так называемым компьютерным наукам. Пусть знания, которые там давали, были недалекими и немного устаревшими, но системный подход у них был сформирован неплохой. Спустя годы практики после окончания обучения я пришел к выводу, что ВУЗовская классификация дисциплин вполне хороша и позволяет ответить на вопрос, что же следует знать любому программисту.

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

В предыдущем абзаце я нарочно ввел термин “инженер-программист”. Как-то получается так, что программист — это не обязательно инженер. Даже из определения Википедии следует, что инженер — это в первую очередь проектировщик. Это тот, кто создает, т.е. проектирует системы. А в практике программирования проектирование нужно не всегда. Иногда достаточно кодирования: используя данный набор технологий, слепить что-то работающее. Типичный пример — стадо корпоративных или маркетинговых сайтов на джумлах, ворпрессах, друпалах и т.д. Это уровень техника, не инженера. Это уровень среднего образования. И работать техником можно даже после окончания курсов какого-либо языка программирования, крепкая теоретическая база там не нужна.

И, возвращаясь к инженерам-программистам, я хочу предложить свой граф дисциплин, которые изучают программисты. Очевидно, что одни дисциплины активно используют знания других, либо вовсе вырастают из других. Соответственно для полного понимания “верхнего” предмета, необходим какой-то уровень понимания нижнего.

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

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

Первый уровень из CS (computer science) — Специальная база. Это стартовая площадка для любого программиста по четырем фронтам:

• арифметические основы ЭВМ (системы счисления и операции с числами, логические операции);

• физические основы ЭВМ (полупроводники, транзисторы, логические элементы, схемы, интегральные микросхемы);

• теория алгоритмов (алгоритмы и структуры данных; сложность, эффективность; способы представления информации в памяти);

• языки программирования (задача и понятие ЯП, уровни, типы языков, абстракция, уровни абстракции, трансляция/компиляция, шаблоны, принципы, парадигмы — обзор).

Специальная база предлагает фундаментальные теоретические знания, на которых строятся дисциплины более высоких уровней. Для среднего программиста необходимы обзорные знания по всем предметам специальной базы. Для некоторых специализаций требуется углубленное понимание теории алгоритмов (прежде всего — разработчикам разного рода библиотек).

Уровнем выше располагаются дисциплины, которые являются базовыми именно в программировании. По-этому я назвал этот уровень Основы. В него входят:

• архитектура ЭВМ (процессоры, микроархитектура, память, шины, ввод/вывод);

• обработка информации (теория информации, статистика, модели, поиск данных, лингвистические аспекты, обработка информации средствами табличных процессоров);

• основы C/C++ (базовые свойства языка, синтаксис, указатели, ввод/вывод, массивы, основы STL).

Следом за Основами идет Уровень 1. Это первый прикладной уровень, и особо нетерпеливые могут начать коммерческую практику, овладев этим уровнем. Он включает 5 дисциплин:

• основы ASM (развитие архитектуры ЭВМ в направлении программирования, написание простейших драйверов и алгоритмов, ассемблерные вставки в C/C++);

• C/C++ (ООП, разработка прикладных приложений, библиотеки, WinAPI, make utils, параллельное программирование).

• операционные системы (архитектура ОС, процессы, межпроцессное взаимодействие, потоки, планирование, работы с памятью и переферией, POSIX-системы);

• системный анализ (предметная область, бизнес-процессы, потоки, диаграммы, принципы и теория системного анализа);

• базы данных (теория множеств, виды СУБД, реляционные СУБД, модели данных, SQL, конкретные БД).

Следующий уровень — Уровень 2 — развивает предыдущий. Кстати, компьютерные сети попали в него только по той причине, что для их изучения желательно (но не обязательно) предварительно освоить операционные системы. По развитости этот предмет ближе все-таки к первому уровню.

Уровень 2 включает:

• разработку ПО (жизненный цикл ПО, этапы разработки, основы ведения программных проектов, инструменты);

• анализ данных (Data Mining, OLAP, машинное обучение, нейронные сети, ИИ);

• компьютерные сети (по уровням стеков TCP/IP и/или ISO/OSI “от и до”, протоколы, сетевое программирование на C/C++);

• языки программирования с управляемым кодом (управляемый код, виртуальные машины, сборщики мусора, юнит-тестирование, собственно практика на C# или Java);

Уровень 3 — последний уровень для среднего программиста. Он самый объемный и включает только те дисциплины, которые непосредственно связаны с разработкой ПО. Всего их получилось 6:

• разработка UI и юзабилити (принципы построения интерфейсов пользователя);

• управление командами и проектами (методологии разработки и другие вопросы управления);

• тестирование ПО (обзорно: виды тестирования, инструменты);

• веб-технологии (HTTP-протокол, веб-сервер, CGI, кэширование и проксирование, клиентское программирование);

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

• интерпретируемые языки программирования (особенности, основы по двум-трем языкам, практика по одному-двум языкам: JS, PHP, Python, Ruby).

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

Интересно в графе то, что он не только показывает предпочтительный порядок изучения предметов, но также:

• дает возможность понять, какие дисциплины нужны больше, какие меньше для работы в определенной специализации (просто выбрать основной предмет специализации и смотреть по связям и удаленности до других);

• дает понимание, как изучать компьютерные науки, если начинать не с фундаментальных основ, а с прикладных знаний (например, PHP) — можно двигаться по связям в стороны и вниз — собственно именно таким был мой личный путь развития (и я никак не могу назвать его самым легким, эффективным и оптимальным).

Граф — это модель. А хорошая модель как правило дает ответы сразу на множество вопросов. Я поставил перед собой задачу сделать хороший граф, близкий к реальности. Естественно, он основан на моем личном опыте и не претендует на идеал. Я старался сделать его наиболее объективным. И еще раз напоминаю, что это граф для программиста. Т.е. для тестировщика, сисадмина и других близких к программированию профессий он будет более или менее близким, но явно другим.

Ценность материала в том, что:

1) это хороший способ взглянуть на себя со стороны огромному числу программистов PHP, так как общая средняя квалификация этого класса программистов значительно ниже среднего по другим более серьезным языкам; взгляд со стороны поможет понять свои проблемы и найти способы их преодоления;

2) конкретные советы о том, что следует почитать/посмотреть.

Ссылка на материал: Как стать хорошим программистом и хорошим php-программистом в частности?

А ниже позволю себе сделать частичный копипаст предложенных решений.

Мастерство программирования (или скорее можно назвать Основы)

• Совершенный код,
• Чистый код,
• Рефакторинг,
• Программист-прагматик,
• Архитектура корпоративных программных приложений,
• Кодеры за работой.

Нашел очень хорошую и исчерпывающую статью на английском: How to be a Programmer: A Short, Comprehensive, and Personal Summary

Курсы, выложенные по MIT OCW:

• MIT Electrical Engineering and Computer Science

Курсы Стэнфорда:

• Mashine learning
• Natural Language Processing class
• Software Engineering for Software as a Service class

На каждом сайте внизу есть ссылки на другие курсы Стэнфорда.

Алгоритмы.

Как развивать:

Искусство программирования Кнутта — читать и выполнять задания.

Project Euer — задания по алгоритмам, можно писать на PHP.

ООП и Шаблоны проектирования

PHP: объекты, шаблоны и методики программирования М. Зандстра сейчас, наверное, лучшая книга для введения в шаблоны проектирвания для PHP.

Head First Design Patterns, на русском Паттерны проектирования — очень рекоммендуют, как очень хорошо разъясняющую книгу.

какие книги, методы обучения, задачи порекоммендуете?

PHP основы

Как развивать:

собственно работа по профессии и набор опыта,

Профессиональное PHP программирование — вроде как лучшая книга по основам PHP (читать, чтобы заполнить пробелы по основам языка, начиная с типов и далее. Посмотреть, что есть из того, чего я не казался в работе, чтобы расширять кругозор.

Потом есть stackoverflow, там введи в поиск ~php~ и читай вопрос, давай свой ответ (про себя), потом смотри, что другие написали. Будешь по тегам смотреть заодно, что пхп-ники изучают.

Javascript Основы

Как развивать:

собственно работа по профессии и набор опыта,

JavaScript. Подробное руководство. Д. Флэнаган (читать и разбираться в пропущенных основах — типы, обьектная модель и др.)

JavaScript: The Good Parts

JavaScript. Шаблоны

Источник: Как стать хорошим программистом и хорошим php-программистом в частности? Ни автор, ни комментаторы не имеют ко мне никакого отношения.

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

Тестовое задание сходу дают не все, а вот резюме читают, пожалуй, все работодатели. В зависимости от конъюнктуры рынка (отношения спроса к предложению) на этапе просмотра резюме отсеиваются до 90 % соискателей. У меня нет точных среднестатистических данных, но эмпирически рискну предположить, что в среднем отсеиваются 60—70% соискателей.

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

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

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

Я постоянно участвую в поиске веб-разработчиков и за последнее время видел много разных резюме. Что особенно важно, приглашая людей на собеседование практически всегда связь между стилем написания резюме и результатами оценки кандидата прослеживается очень хорошо. Хорошее, подробное резюме с информацией по делу — кандидат хороший. Куча воды, названий технологий, но отсутствие четкой информации по опыту работы — кандидат «ниочем».

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

С позиции работодателя расскажу о своем видении резюме веб-разработчика. Язык программирования при этом значения не имеет.

От соискателя в резюме важно получить следующую информацию:

1. минимальную информацию о себе, как о личности;
2. краткую информацию об образовании;
3. подробную информацию о предыдущих местах работы;
4. подробную информацию о навыках и опыте соискателя в контексте вакансии (позиции, должности).

Эти четыре пункта обычно содержит любое резюме по любой специальности. И на этом уровне оно стандартное. А вот какую информацию нужно писать по этим пунктам и как ее преподнести? Это уже позиционно-уникально.

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

1.1) ФИО (отсюда станет ясен пол, так что писать нужно полностью)
1.2) Год рождения (или возраст, если резюме рассчитано на короткий период)
1.3) Город (место жительства, адрес не нужен)
1.4) Семья (брак, дети)
1.5) Образование (высшее/среднее/базовое или др.)
1.6) Отношение с армией (не обязательно писать, но все равно об этом спросят)
1.7) Иностранные языки (перечислить языки с указанием уровня влядения; не стоит тут писать русский, украинский или белорусский)
1.8) Позиция (должность; в одной организации может быть несколько вакансий, к которым подойдет ваше резюме, поэтому указать позицию или позиции, на которые претендует соискатель, нужно обязательно)
1.10) Желаемая заработная плата (реальная заработная плата, на которую нацелен соискатель в настоящее время; это очень важная для работодателя информация, и если соискатель знает, что он хочет, нужно обязательно указать, если не знает — на это укажет отсутствие данной информации; можно писать в стиле «от Х»)

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

2.1) Учебное заведение
2.2) Факультет
2.3) Специальность
2.4) Годы обучения (лучше указать время начала и окончания обучения, т.к. иногда возникают непонятные ситуации, когда указан только один год)
2.5) Окончен ли успешно? (если обучение прервано, об этом обязательно нужно написать отдельно)

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

3.1) Название компании (так, как оно пишется «в миру»)
3.2) Сколько человек в организации/подразделении (опционально, если компания неизвестная, просто поможет оценить ее масштаб)
3.3) Должность (позиция, так, как она называлась в компании; можно дополнить общепринятым названием позиции, если оно отличается от принятого в компании)
3.4) Время работы (лучше всего в формате мм.гггг — мм.гггг / н.в.)
3.5) Обязанности (тезисно: что реально входило в круг обязанностей, пояснения и комментарии будут уместны)
3.6) Сколько человек в подчинении (если были люди в подчинении, об этом обязательно стоит упомянуть, иначе — пропускается пункт — 0 писать не нужно)
3.7) Проекты (это отдельный список проектов, в которых соискатель принимал участие в компании; если подход не проектный или если нет желания все расписывать, можно просто описать в текстовом виде, что соискатель сделал, работая в компании)
3.7.1) Название проекта с кратким описанием (из этого должно быть понятно, какие разработки велись в рамках проекта)
3.7.2) Временные рамки участия в проекте
3.7.3) Результаты (как личные, так и общие)
3.8) Причина ухода (если указывать желания нет, не надо, но все равно скорее всего на собеседовании спросят)

4) Технологии
Очень важный блок. Из него должно стать понятно, каким навыками соискатель владеет, с какими технологиями имел опыт работы и какой этот опыт, как соискатель оценивает свои знания. Информация обычно подается в табличном виде с колонками: название технологии, оценка своего уровня (по любой шкале, но не менее чем из 3-х уровней: начальный, средний, продвинутый), сколько лет опыта.
Здесь нужно писать только то, что уместно в контексте позиции. Не стоит указывать технологии, по которым уровень соискателя такой, который не позволит применение технологии на практике без дополнительного обучения. Информация разбивается на отдельные группы:

4.1) Языки программирования, разметки, запросов и т.д. (т.е. все, что является языком чего-либо или близко к этому)
4.2) Фрэймворки и библиотеки (стоит указывать только общеизвестные; нет смысла указывать самостоятельно разработанные библиотеки и фрэймворки, если ими пользуется только сам соискатель или его [бывшие] коллеги)
4.3) Технологии (то, что не является языком или библиотекой, но существует как стандартизированная и/или общеизвестная технология: AJAX, Web Services (SOAP), COM/OLE и т.д.)
4.4) Операционные системы (если у соискателя в арсенале опыт работы только с несколькими версиями Windows, этот пункт лучше вообще опустить; он имеет смысл, когда есть опыт работы с 2-мя и более разными ОС; версии одной и той же ОС лучше объединить в одну строку; разные дистрибутивы Linux/BSD/UNIX = разные ОС; необходимо указание уровня: администрирование сервера, либо использование в качестве десктопа)
4.5) Прикладное программное обеспечение (IDE, ПО для проектирования, разработки, тестирования, специфичное для специальности; не стоит сюда писать программы общего назначения, такие как Total Commander, FAR,  MS Office, gedit и т.д.)
4.7) Другое (если есть еще что-то важное, о чем соискателю хочется рассказать, следует это сделать)

Резюме лучше всего распространять в формате PDF. Если в качестве формата все же выбран Microsoft Word, то это должен быть формат DOC не выше версии Word 2003. Категорически не рекомендуется размещать резюме прямо в письме или в текстовом файле. Лучше сделать вложение к письму (не стоит размещать ссылку на скачивание резюме). Невыполнение этих требований говорит о неуважении к работодателю и вызывает аналогичное отношение к соискателю.

В моей практике был случай, когда в ответ на вакансию я получил письмо следующего содержания: «Здравствуйте. Слать резюме надоело, поэтому не буду. Если у вас действительно есть сложные задачи и хорошо поставлен рабочий процесс, звоните +37529…..». Сомневаюсь, что с таким подходом человеку удастся найти работу. Естественно, это письмо я проигнорировал. Через несколько дней этот человек перезвонил по телефону. Конечно, стоило сразу сообщить ему, что даже разговаривать с ним нет желания. Но я этого не сделал, и постарался более-менее вежливо с ним поговорить. Через пару минут разговор был закончен по смыслу тем, что он нам не подходит.

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

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

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

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

Факторную модель можно составить для любой специальности, но она должна быть специализирована. Делать универсальную модель для всех сразу нет смысла — ее точность будет очень плохая. Я составил модель для своей специальности — разработчик ПО.

Факторный анализ места работы для разработчика ПО

1. Интерес
   • Проект
     • тематика
     • технологии
     • уровень сложности
     • нагрузки в продакшане
   • Зона ответственности
     • разброс обязанностей
     • принятие решений
   • Подчиненные
     • количество
     • качество
   • Заказчик
     • локальность
     • культурные различия
     • требовательность
2. Условия труда
   • Офис
     • эстетика
     • расположение
     • размер, оформление  комнаты и ключевых узлов
     • вентиляция и кондиционирование
     • ремонт (состояние)
     • стоянка
   • Рабочее место
     • компьютер
     • монитор
     • админские права и ограничения по ОС/ПО
     • интернет и ограничения
     • стол, стул
     • освещение
   • Коллеги и руководство
     • размер команды
     • адекватность руководителя
     • простота административной структуры
     • постановка работы команды
   • График
     • время работы
     • гибкость графика
     • отработки
3. Оплата
   • Зарплата
     • сумма
     • валюта
     • рост
   • Социальные вопросы
     • социальный пакет
     • корпоративы
   • Проблемы
     • задержки зарплаты
     • штрафы
     • ограничения контракта

Оценка по каждому фактору:

• 0 — нейтрально, нормально,
• ­­−1 — плохо,
• +1 — хорошо.

Проставляется оценка по каждому фактору 3-го порядка. Важно понимать, что оценка +1 всегда обозначает, что по данному вопросу обстоятельства в вашу пользу. Не важно как называется фактор: «уровень зарплаты» или «штрафы», +1 всегда будет обозначать, что по этому фактору вы в положении «хорошо» для себя. Соответственно −1 — значит «плохо» для вас.

Оценки суммируются по группам — факторам 1-го порядка. Каждому фактору 1-го порядка выставляется субъективный вес, который приводится к коэффициентам. Например, устанавливаются веса: «Интерес» — 10, «Условия труда» — 7, «Оплата» — 8. Тогда коэффициенты будут: «Интерес» — 40% (10/(10+7+8)=0,4), «Условия труда» — 28% (0,28), «Оплата» — 32% (0,32).

Коэффициент при факторе 1-го порядка покажет, какую долю в оценке займет этот фактор. Такой подход позволяет сильно влиять на результат в зависимости от предпочтений разных людей не меняя модели: кому-то уровень заработной платы в 2 раза (условно) важнее интереса в работе, а кому-то наоборот. В первом случае «Интерес» может получить 20%, «Оплата» — 40%, во втором соответственно наоборот.

Полученная сумма по каждому фактору 1-го порядка умножается на коэффициент этого фактора и делится на количество его факторов 3-го порядка. Затем полученные числа суммируются.

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

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

Самый лучший способ заполнить факторную модель — наличие «своего» человека в организации. Это особенно актуально, когда работу предлагают по рекомендации.

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

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

Модель должна быть сбалансирована по факторам 2-го порядка. Если фактор 2-го подяка имеет важное и широкое значение, то факторов 3-го порядка в нем должно быть много. Если значение слабое — мало. В остальных случаях количество факторов 3-го порядка должно быть примерно равным и относительно небольшим.

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

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

Немного подробнее о самом вопросе. Зачастую встречаются сайты, работающие на одной кодовой базе на одном сервере, но, при этом, на разных доменах. При схожем внешнем виде на этих сайтах содержится разная информация в разном дизайне.

Самый простой пример таких сайтов — это локализованные версии одного сайта на разных языках. У меня в практике — это тематические форумы для разных групп.

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

При запуске обработки пользовательского HTTP-запроса скриптам необходимо определить, какому именно домену предназначен запрос, и выбрать соответствующий конфиг. В PHP это довольно просто сделать: заглянуть в переменную $_SERVER[‘SERVER_NAME’]. В других языках программирования под веб, думаю, примерно так же просто.

По имени серевера определяется нужный конфиг и оттуда берутся все необходимые настройки. Все просто.

Но когда дело доходит до вызова скриптов из cron-а (или другого планировщика), то переменная $_SERVER[‘SERVER_NAME’] будет пуста. Оно-то и понятно: никакого сервера нет, скрипт запускается напрямую через CLI. И узнать, для какого сайта вызывается скрипт, без явной передачи домена скрипту невозможно.

Самый простой способ указать домен — это прописать его аргументом командной строки. При вызове из cron-а после имени скрипта просто пишем домен, а в коде получаем его из переменной $argv глобальной области видимости.

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

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

Таким образом ищем более удобный способ передать «указатель» на сайт. И находим: это переменные окружения. Среду окружения интерпретатор PHP получает оттуда, откуда он был запущен. Если скрипт запущен веб-сервером, то переменные будут получены от сервера. Если запускается скрипт через CLI, то среда будет получена от shell-а, в котором производился запуск. Повторю: запуск скриптов из cron-а — это обыкновенный запуск исполнимого файла в режиме CLI.

Теперь к конкретике. Чтобы переменная среды окружения попала из веб-сервера в PHP-скрипт (или скрипт/программу, написанную на других языках), ее надо установить (прописать). Для Апача установить переменную можно в файле .htaccess, либо в конфигах сервера (httpd.conf или конфиги виртуальных хостов). В идеале предпочтительно последнее. Но достаточно и минимального уровня доступа к .htaccess. Добивим в соответствующий конфиг строку:

SetEnv SITE_NAME site1

Чтобы определить переменную среды при запуске в режиме CLI (php /filename), нужно ее объявить и экпортировать:

export SITE_NAME=site1;

При запуске скрипта вручную следующей командой можно запускать сам PHP. Если запуск производится cron-ом, то стоит создать скрипт, на который ссылаться из crontab:

#!/bin/bash
export SITE_NAME=site1;
php /path

Для других сайтов вместо site1 подставляются другие имена.

Остается прочитать переменную в скрипте:

echo getenv('SITE_NAME');

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

* Стоит отметить, что в случае разных «установок»¹ одного и того же сайта (development, testing, production) принято это значение передавать сайту в виде тоже же переменной окружения. Как правило, конфиг в этом случае содержит очень много информации, одинаковой для всех «установок», а отличаться, например, могут только параметры доступа к БД. Тогда имеет смысл все установки считать за один сайт (хоть домены и разные), а отличающиеся параметры вынести в отдельный конфиг, зависимый от «установки».

¹ — Я намеряно в последнем абзаце заменил термин «окружение приложения» (application environment: тестовое, рабочее) на «установку», чтобы не было путаницы с тем окружением, где устанавливаюся переменные.

Виджет очень пока простой, содержит самый базовый функционал. Размер виджета минимальный — 1×1. При нажатии на его видимую обалсть выполняется USSD-запрос на получение баланса лицевого счета: *100#. Такой запрос используется в Беларуси всеми тремя GSM операторами.

База логотипов в программу встроена. На данный момент поддерживается только 4 оператора: МТС (Беларусь), Velcom, Life:) и Dialog. Распознавание оператора произыодится по коду сети. Название оператора в любом случае отображается так, как его отдает сеть.

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

В данный момент доработана первая публичная версия. Статус — бета.

Сайт программы.

Скачать:

Чтобы решить проблему отказа серверов Gmail от обслуживания  при отправке большого числа писем на несуществующие адреса, используем для отправки почты из скриптов сайта локальный почтовый SMTP-сервер (MTA). Локальный сервер будет выступать в качестве mail relay. В дополнение мы откажемся от подключения из скрипта к удаленному серверу, что может быть медленно. Локальные подключения всегда должны быть быстрее и стабильнее.

Локальный сервер мы будем использовать только для отправки писем. Причем, не важно, как будет происходить отправка: непосредственно через SMTP, или с помощью MUA. Получение почты по-прежнему будет происходить с серверов Gmail.

В дистрибутиве Debian 5 по умолчанию устанавливается MTA Exim4. Он отлично подойдет для наших задач. Причем его настройка производится с помощью мастера и невероятно проста. Настроить сервер требуется на прием соединений исключительно с локального соединения. При этом не нужно поручать ему обслуживание доменов, кроме дефолтного локального (localhost).

Итак, если Exim у вас не установлен, то установим его:

# aptitude install exim4

Далее запускаем его конфигурацию:

# dpkg-reconfigure exim4-config

1. На первом шаге необходимо выбрать конфигурацию сервера. В Exim есть несколько стандартных конфигураций, предназначенных для разных случаев. Подробнее о них в мануале. Нам нужна конфигурация “internet site; mail is sent and received directly using SMTP”.

2. Далее укажите имя сервера. Оно будет передаваться в SMTP-протоколе в команде HELLO, т.е. будет видно получателям вашей почты. Лучше всего, чтобы это имя совпадало с доменом, с которого шлется почта. Например, valera.ws.

Если у вас на сервере несколько сайтов с разными доменами (см. ниже), то лучше это имя сделать нейтральным, чтобы «не палиться». Например, можно выбрать local-mail-agent.

3. Далее требуется указать, какие интерфейсы должен слушать Exim. В нашем случае удаленные подключения мало того, что не нужны, так еще и опасны: кто угодно сможет рассылать почту через ваш сервер. Указываем только 127.0.0.1.

4. Далее спрашивается, какие домены должен обслуживать сервер. Т.е. для каких доменов не нужно пересылать письма на удаленные SMTP-сервера, пользователь заберет их с этого сервера. Нам не нужно обслуживание наших доменов. Можно указать только localhost, т.к. его больше обслужить некому.

Не указывайте здесь адрес вашего сервера (подставляется по умолчанию), т.к. его обслуживание делегировано Gmail. Если его указать, то письма, отправленные на ящики вашего домена, в Gmail не попадут и останутся на сервере. Это не нужно.

5. Далее можно указать, для каких доменов сервер должен служить релеем (список через точку с запятой). Здесь не указываем ничего, так как на следующем шаге мы разрешим себе релей для всех доменов. Можете указать список ваших доменов.

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

При этой конфигурации есть один негативный момент. Если ваш сайт поломают, то злоумышленники смогут слать почту с любых доменов через ваш сервер. Если на сервере 1—2 сайта, то лучше на этом шаге оставить поле пустым, а на предыдущем шаге внести список этих доменов (для возврата на шаг назад нажмите кнопку “Cancel”). При появлении новых доменов не забывайте их заносить в конфиг. Если вы считаете свои сайты надежными, то проще всего указывать здесь 127.0.0.1.

7. Дале уточняется, является ли для нас проблемой постоянные DNS-запросы при отправке каждого письма. В 99,9% это не проблема, так что выбираем ответ на вопрос “Keep number of DNS-queries minimal (Dial-on-Demand)?” “No”.

8. Где хранить локальную почту (помните, мы указали серверу обслуживать домен localhost?) нам по сути не важно, так как этим как правило никто не пользуется. Можно выбрать вариант по умолчанию: складывать все в /var/mail.

9. Предпоследний шаг — выбор конфигурации. Хранить все в одном файле, или раскидать по множеству мелких файлов. В большой файл проще вносить большие изменения, а с мелкими проще работать в случае мелких правок. Выберите вариант на свой вкус. Я выбрал “unsplit configuration” (ответ “No”).

10. На последнем шаге укажем на какой аккаунт реального пользователя системы пересылать сообщения, отправленные на служебные аккаунты postmaster, root и т.д. Здесь имеет смысл указать ваше имя пользователя в системе.

Переконфигурировать Exim в любой момент можно тем же способом. Мастер подставит в значения по умолчанию текущие значения вашей конфигурации.

Правильная настройка SPF

Если кратко, то SPF — это способ борьбы со спамом.

Мы собираемся отправлять почту с сервера, PTR IP которого не равен одной из MX-записей сервера, а так же в большинстве случаев PTR IP не равен самому нашему домену (не всегда хостеры соглашаются менять PTR). В этом случае вероятность попадания писем в спам повышается. Но есть хороший способ ее понизить: указать правильно запись SPF нашего домена.

SPF-запись — это обыкновенная запись доменной зоны, имеющая тип TXT. Узнать текущее ее значение для домена можно с помощью команды host в Linux:

$ host -t TXT valera.ws
valera.ws TXT record currently not present

В данном примере SPF-запись не задана. Зададим ее. С моего домена почта может отправляться с серверов Gmail и с моего сервера. Для начала узнаем, какой PTR моего сайта (valera.ws):

$ nslookup valera.ws
Server:      194.224.52.4
Address:     194.224.52.4#53

Non-authoritative answer:
Name:     valera.ws
Address:  93.174.6.118

IP-адрес моего сервера 93.174.6.118. Узнаем PTR:

$ nslookup 93.174.6.118
Server:      194.224.52.4
Address:     194.224.52.4#53

Non-authoritative answer:
118.6.174.93.in-addr.arpa name = server.valera.ws.

Видно, что PTR IP, к которому привязан мой домен (IP моего сервера) — server.valera.ws.

v=spf1 a mx ptr include:_spf.google.com ~all

По порядку:

• v=spf1 — версия SPF (первая);
• a — разрешение отправлять почту с IP, указанного в A-записи домена (собственно с сервера, на который ваш домен ссылается);
• mx — разрешение отправлять почту с IP, указанных в MX-записях домена (в нашем случае сервера Gmail);
• ptr — разрешение отправлять почту с IP, PTR-запись которых содержит ваш домен (т.е. сам домен и поддомены);
• include:_spf.google.com — подключение разрешений для серверов отправки почту Gmail (совсем не обязательно почта будет слаться с серверов, указанных в MX-записи);
• ~all — нейтральная реакция на всю остальную почту; здесь можно указать -all, что будет значить, что почта, не попадающая под эти правила, — спам.

Если вы хотите отправлять почту с сервера, не попадающего под все эти правила, его можно указать по IP или домену PTR, например:

v=spf1 a mx ptr ptr:example.com include:_spf.google.com ~all

Запись указывается для вашего домена соответствующим образом, который определяет владелец DNS-сервера. Обычно сервером заведует хостер и предоставляет возможность вносить изменения в DNS-зоны через панель хостинга. Либо сам по запросу в саппорт меняет запись. В зональном файле должна появиться запись вида:

valera.ws.      TXT      v=spf1 a mx ptr include:_spf.google.com ~all

После обновления зоны host выдаст следующее:

$ host -t TXT valera.ws
valera.ws      TXT      «v=spf1 a mx ptr include:_spf.google.com ~all»

PHP mail()

После всей этой настройки функция mail() в PHP начнет слать почту через ваш локальный сервер на законных основаниях для антиспам-ботов. Но косяк будет в том, что в поле отправителя будет фигурировать адрес системного пользователя www-data@localdomain. Нас это не устраивает. Чтобы почта правильно слалась из mail(), необходимо использовать ее дополнительный параметр.

bool mail ( string $to , string $subject , string $message [, string $additional_headers [, string $additional_parameters ]] )

Именно $additional_parameters нас и интерисует. В него надо передавать реального отправителя:

mail($to, $subject, $message, $additional_headers, $additional_parameters.» -frealsender@valera.ws»);

Указывается отправитель слитно с параметром -f.

Теперь отправленные через mail() письма будут абсолютно адекватны (при условии, что вы указываете все нужные SMTP-заголовки, вроде “FROM:”, “TO:” и т.д.).

А если несколько сайтов с разными IP (настройка Exim для отправки писем с разных IP)?

Мы хотим использовать локальный SMTP-сервер для отправки почты со всех сайтов на сервере. Никаких проблем нет, если настроен Exim правильно (см. выше). Но проблема появляется, если разные сайты работают на разных IP. Мы не хотим в почте «палить» то, что все наши сайты живут на одном сервере. Но Exim по умолчанию шлет всю почту с основного (первого) IP сетевого интерфейса, а этот IP всем получателям в SMTP-заголовках “Received:” письма. Кроме того, там указывается и имя сервера, которые мы в случае с разными сайтами на сервере выбрали нейтральными.

Чтобы не «палить» IP сервера, нужно отсылать письмо на удаленный сервер с IP, равного A-записи домена сайта. Делается это несложно путем изменения конфига Exim. Внесем изменения в настройки транспорта SMTP Exim. Если вы выбрали монолитный конфиг, то нужно отредактировать файл:

# nano /etc/exim4/exim4.conf.template

Находим в файле строку “remote_smtp:” (поиск в nano — F6). Добавляем в конец этого блока:

interface = «${lookup{$sender_address_domain}lsearch{/usr/share/exim4/domain2ip}{$value}}»
helo_data = «$sender_address_domain»

Это значит, что при отправке письма нужно определить домен отправителя почты (для sender@valera.ws это valera.ws) и отправить почту с IP, к которому этот домен привязан. Само собой разумеется, что домен должен быть привязан к серверу, где установлен Exim.

Так же нужно создать файл в любом месте файл привязки доменов к IP (у домена может быть несколько IP, так что просто lookup-ить его не прокатит). Я выбрал для файла место: /usr/share/exim4/domain2ip

# nano /usr/share/exim4/domain2ip

Туда вводим наши домены по шаблону:

valera.ws: 123.123.123.123
vasya.ws: 123.123.123.124

Не забудьте дописать домен в файл в случае появления нового сайта.
Кстати, строку helo_data = «$sender_address_domain» можно добавить в файл даже если у вас один IP на все сайты. Тогда в команде HELLO SMTP-протокола (а, следовательно, и в заголовках писем) будет фигурировать ваш домен.

Идея с указанием интерфейса взята отсюда: http://www.directadmin.com/forum/showthread.php?t=36468

Проверка

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

$ mail -a «From:feedbee@valera.ws» -s Test feedbee@gmail.com — -ffeedbee@valera.ws
Test <Ctrl-D>
Cc:

Проверяем отосланное письмо в ящике получателя:

А вот текст SMTP-протокола:

Delivered-To: feedbee@gmail.com
Received: by 10.236.109.139 with SMTP id s11cs13826yhg;
Wed, 24 Nov 2010 02:18:14 -0800 (PST)
Received: by 10.227.145.134 with SMTP id d6mr9025492wbv.195.1290593893066;
Wed, 24 Nov 2010 02:18:13 -0800 (PST)
Return-Path: feedbee@valera.ws
Received: from valera.ws (server.valera.ws [93.174.6.118])
by mx.google.com with ESMTP id b7si11085685wer.164.2010.11.24.02.18.12;
Wed, 24 Nov 2010 02:18:12 -0800 (PST)
Received-SPF: pass (google.com: domain of feedbee@valera.ws designates 93.174.6.118 as permitted sender) client-ip=93.174.6.118;
Authentication-Results: mx.google.com; spf=pass (google.com: domain of feedbee@valera.ws designates 93.174.6.118 as permitted sender) smtp.mail=feedbee@valera.ws
Received: from root by server.valera.ws with local (Exim 4.69)
(envelope-from <feedbee@valera.ws>)
id 1PLCQW-0006KD-Pc
for feedbee@gmail.com; Wed, 24 Nov 2010 10:18:12 +0000
To: feedbee@gmail.com
Subject: Test
From:feedbee@valera.ws
Message-Id: E1PLCQW-0006KD-Pc@server.valera.ws
Date: Wed, 24 Nov 2010 10:18:12 +0000

Test

P.S. Чтобы отправленная почта не попадала в спам, отправляйте письма только от имени реально существующих на серверах Gmail адресов на ваших доменах. Туда же повалятся уведомления о недоставках.

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

Первым длом полез в гугл. Зачем делать работу, которую уже наверняка кто-то сделал? Так и оказалось, сразу нашел довольно неплохой план собеседования (ссылки внизу). Взял из него большуючасть вопросов и добавил свои.

Естественно, что вопросов программисту PHP можно задать море. Особенно учитвая, что знать надо связанные области (БД, сети, HTML и иже с ним, Linux). Смысла задать все вопросы, какие только можно, конечно нету. Задача — определить уровень специалиста, чтобы принять решение: подходит он нам или нет. По-этому выбрал наиболее подходящие на мой взгляд вопросы, по которым я смогу оценить уровень кандидата.

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

Вопросы

1. PHP и основы программирования
1.1. Почему PHP?
1.2. Что такое ООП, основные принципы ООП.
1.3. Понятие абстракции, наследования, инкапсуляции и полиморфизма.
1.4. Что такое MVC?
1.5. Какие паттерны проектирования вам известны?
1.6. Под какую версию PHP писали? В чем различия между четвертой и пятой версиями?
1.7. Какими сторонними библиотеками пользовались?
1.8. Опыт работы с различными Frameworks/CMS?
1.9. Типы данных в PHP? (string, int, float, object, resource, null, bool, array)
1.10. Назовите по памяти функции для работы с массивами, строками и объектами в PHP (хотя бы по 5 штук).
1.11. Что такое сериализация?
1.12. Чем отличается абстрактный класс от интерфейса?
1.13. В каких случаях лучше использовать статические методы и классы?
1.14. Можно ли создать приватный конструктор? Зачем?
1.15. Как сказывается большое количество объектов в коде на производительность?
1.16. Что такое хэш?
1.17. Что такое область видимости переменной?
1.18. Что такое PDO? Что такое ORM?
1.19. Что такое PEAR?
1.20. Когда лучше использовать mysql_pconnect?
1.21. Обязательно ли писать ?> в конце скрипта?
1.22. Как вы отлаживаете PHP-код?
1.23. Проводили когда-нибудь оптимизацию сайтов?
1.24. Какую IDE используете? Какие использовали ранее?
1.25. Что такое unit-test? Использовали?
2. Tools
2.1. Что такое Apache? mod_rewrite? nginx?
2.2. Аббревиатуры SVN и CVS о чем-нить говорят? А Git и Mercurial?
2.3. Багтрекинг системы? BugZilla? Mantis? Redmine? JIRA?
2.4 .Моделирование, UML использовали?
2.5. Что такое SSH? Какие есть варианты авторизации при входе по SSH?
3. Data Bases
3.1. Что такое реляционная база данных? Какие есть типы БД?
3.2. Нормализация, денормализация.
3.3. SQL. Join’ы, Union. Подзапросы.
3.4. Процедуры, тригеры.
3.5. Вьюшки.
3.6. InnoDB vs MyISAM.
3.7. Какие бывают индексы в MySQL?
3.8. В чем отличие MySQL от PostgreSQL?
3.9. Что такое SQL-инъекция? Приведите пример.
4. HTML + CSS
4.1. Нарисуйте простенькую форму для отправки файла.
4.2. Что такое CSS? В чем разница между записью #my и .my? Для каких атрибутов можно указать :hover?
4.3. Расшифруй вот такую запись в CSS table#a tbody td.odd {text-decoration:inherit}?
4.4. Что такое стандарты W3C?
5. JavaScript
5.1. Как работает наследование в JS?
5.2. Чем отличается хэш от объекта? (провокационный)
5.3. А хэш от массива?
5.4. Если ли опыт работы с Jquery, ExtJS? Какие фреймворки использовались?
5.5. Что такое Ajax? Есть ли опыт работы с ним?
5.6. Использовали ли FireBug? Drag-on-fly?
5.7. Что такое замыкания и как они работают?
6. Linux
6.1. С *nix знаком? Какие дистрибутивы? Почему?
6.2. Apache, PHP и СУБД устанавливали под *nix? Настраивали? Оптимизировали?
7. Networking
7.1. Что такое уровни модели OSI? Сколько их?
7.2. По какому протоколу осуществляется передача данных в сети Интернет?
7.3. Какие вообще есть сетевые протоколы?
7.4. Расскажите, что происходит, когда в строке браузера набираешь адрес и нажимаешь Enter?
7.5. Что такое WSDL & web-services? Есть опыт работы?
7.6. Что такое SSL? Как работает HTTPS? Какой принцип работы HTTPS? Какие есть варианты авторизации HTTP?
8. Что такое XSLT, XML? Есть ли опыт работы с ними?

Как отработает код?

1)
<?php
/* Что будет выведено на экран? */
$a = ‘true’;
if( 0 == $a || $a )
{
echo ‘yes’;
}

2)
<?php
/* Что будет выведено на экран? */
$a = 10;
echo $a— — — — — — — — — — — —$a;

3)

<?php
class A {private function __construct(){throw new Exception(»);} public function A(){return array(‘a’,’b’,’c’);} public static function I(){return new A();}}
/*
Как вывести на экран именно то ‘b’, которое определено в массиве выше, используя одну команду (одну строку кода)?
*/

4)
<?php

/*
Какая строчка выведется при исполнении скрипта?
Почему исполняется или не исполняется каждое из условий?
*/
$x = 1;
if ($x == ‘1’) {
echo ‘a’;
}
if ($x == true) {
echo ‘b’;
}
if((bool)$x === true){
echo ‘e’;
}
if ($x === true) {
echo ‘c’;
}
if((int)$x === true){
echo ‘d’;
}

5)
<?php
/*
Что выведет скрипт? (запускается непосредственно)
*/
error_reporting(E_ALL);
ini_set(‘display_errors’,’0′);

print $x[0];
dddxxxx();

6)
<?php
/*
Для какой версии PHP будет работать этот скрипт?
Что выведет этот скрипт?
*/
class Test{

private $var;

function setMe($value){
$this->var = $value;
}
}

class More extends Test{
public $var;
}

$oTest = new Test;
$oMore = new More;

echo $oTest->setMe(‘foo’);

echo $oMore->setMe(‘foo’);

echo $oMore->var;

echo $oTest->var;

Тест на corp.mamba.ru

http://www.corp.mamba.ru/test/promo.phtml

Ссылки

А вот и те ссылки, которые помогли мне в составлении списка.

http://habrahabr.ru/blogs/php/21681/

http://habrahabr.ru/blogs/webdev/19964/

function makeEaste(year)
{
    a = (19*(year%19) + 15) % 30;
    b = ((2*(year%4) + 4*(year%7) + 6*a + 6) % 7);
    if(a + b > 10)
        p = new Date(year, 3, a + b - 9, 0, 0, 0, 0);
    else
        p = new Date(year, 2, 22 + a + b, 0, 0, 0, 0);
    p.setDate(p.getDate()+13);
    return p;
}

Так как на 10й день после пасхи идет Радоница, получить ее дату можно так: p = makeEaste(year); p.setDate(p.getDate()+9);

З.Ы. Я не AS программер, так что если какие глупые ошибки в коде — не серчайте.

Update. Код на JavaScript:

function makeEaste(year)
{
    var a = (19*(year%19) + 15) % 30;
    var b = ((2*(year%4) + 4*(year%7) + 6*a + 6) % 7);
    if(a + b > 10)
        var p = new Date(year, 3, a + b - 9, 0, 0, 0, 0);
    else
        p = new Date(year, 2, 22 + a + b, 0, 0, 0, 0);
    p.setDate(p.getDate()+13);
    return p;
}

Код на PHP:

function makeEaste($year)
{
    $a = (19*($year%19) + 15) % 30;
    $b = ((2*($year%4) + 4*($year%7) + 6*$a + 6) % 7);
    $p = new DateTime();
    if($a + $b > 10)
        $p->setDate($year, 4, $a + $b - 9);
    else
        $p->setDate($year, 3, 22 + $a + b);
    $p->modify("+13 day");
    return $p;
}