Кроссдоменный ajax-запрос с помощью jquery

Столкнулся с тем, что по соображениям безопасности Chromium не отображает ajax-запросы, приняты с домена, отличного от того, на котором отрабатывается javascript.

Решением стал вот такой код

Continue reading


Цели, задачи и структура отдела программирования

Обеспечение поддержки отделов не связанных с разработкой

Поддерживаемые отделы

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

  1. сопровождения сайтов
  2. технической поддержки
  3. продаж
  4. поисковой оптимизации оптимизации и продвиже ния

Виды работ

Поддержка осуществляется путём выполнения следующих видов работ:

  1. внесение мелких исправлений в программный код сайтов заказчиков, которые не реализуют какого-то нового функционала с точки зрения посетителя, но позволяют их более качественно продвигать;
  2. исправление ошибок в программном коде сайтов заказчиков, которые могут отрицательно сказаться на отношении с ними и результатах продвижения;
  3. исправление ошибок в программном коде сайтов заказчиков, связанных с переносом сайта на новую хостинговую площадку;
  4. оперативное вмешательство в код сайтов заказчиков, с целью ликвидации действий злоумышленников;
  5. оперативной вмешательство в код внутренних проектов, при обнаружении ошибок открытого характера, делающих невозможным использование системы;
  6. срочное восстановление работоспособности внутренних проектов и сайтов заказчиков из резервное копии;
  7. консультирование представителей поддерживаемых отделов по техническим вопросам.

Разработка сайтов

Поддерживаемые отделы

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

Виды работ

Поддержка осуществляется посредством выполнения следующих видов работ:

  1. консультирование представителей отдела разработки сайтов и web-дизайна относительно сроков, трудозатрат и стоимости разработки необходимого им программного кода силами и средствами тактической группы отдела программирования;
  2. проектирование и разработка БД и программного кода, необходимого отделу разработки сайтов и web-дизайна для реализации нужных клиенту и закреплённых в техническом задании сервисов согласно установленным правилам разработки приложений для клиентов.

Разработка ПО для внутренних нужд

Поддерживаемые отделы

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

При разработке ПО для внутренних нужд отдел программирования обязан:

  1. принимать участие в обсуждении возможностей будущего ПО и требований к нему;
  2. спроектировать и реализовать БД и программный код внутреннего ПО, согласно правилам разработки приложений для внутреннего использования

Состав отдела программирования

Для решения задач и достижения целей, описанных в п.1 отдел программирования имеет в своём составе следующие группы:

  1. оперативная группа;
  2. тактическая группа;
  3. стратегическая группа;

Оперативная группа

Оперативная группа предназначена для решения задач:

  1. внесение любых небольших по объёму и срочных изменений в код проектов заказчиков или внутренних проектов, для ликвидации очевидных и на 100% воспроизводимых ошибок, возникших по любой причине;
  2. внесение в код проектов разазчиков или внутренних проектов любых изменений, направленных на увеличения эффективности продвижения;
  3. консультирование поддерживаемых отделов по техническим вопросам;
  4. оценка трудозатрат, необходимых на решение поставленных задач.

Тактическая группа

Оперативная группа предназначена для решения задач:

  1. проектирование и разработка БД и программного кода, необходимого отделу разработки сайтов и web-дизайна для реализации нужных клиенту и закреплённых в техническом задании сервисов согласно установленным правилам разработки приложений для клиентов;
  2. консультирование поддерживаемых отделов по техническим вопросам;
  3. консультирование оперативной группы отдела программирования по вопросам реализации сайтов заказчиков;
  4. оценка трудозатрат, необходимых на решение поставленных задач.

Стратегическая группа

Стратегическая группа предназначена для решения задач, описанных в п. 1.3, а именно

  1. проектирование и реализация БД и программного кода внутреннего ПО, согласно правилам разработки приложений для внутреннего использования
  2. консультирование оперативной группы отдела программирования по вопросам реализации сайтов заказчиков;
  3. оценка трудозатрат, необходимых на решение поставленных задач.

Критерии оценки качества работы групп

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

  • своевременность;
  • объёмы работ;
  • качество реализации.

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

Критерии оценки оперативной группы

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

  1. своевременность;
  2. качество реализации;
  3. объёмы работ.

Основной критерий

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

Задачи, оформляемые для этой группы в dotproject имеют высокий приоритет, и премиальный коэффициент за своевременность самый большой из 3-х групп. Дополнительный критерий

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

Второстепенный критерий

Низшим приоритетом в оценке работы оперативной группы является критерий объёма выполненной работы. Среди групп отдела программирования премиальный коэффициент за объёмы выполненной работы — наименьший.

Критерии оценки тактической группы

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

  1. объёмы работ;
  2. своевременность;
  3. качество реализации.

Основной критерий

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

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

Задачи, оформляемые для этой группы в dotproject имеют нормальный приоритет.

Второстепенный критерий

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

Критерии оценки стратегической группы

Характер работы стратегической группы — написание качественного, логически стройного, качественно спроектированного и тщательно задокументированного кода, для внутреннего использования. Отсюда вытекает следующий приоритет критериев оценки работы:

  1. качество реализации;
  2. объёмы работ;
  3. своевременность;

Основной критерий

Основной критерий в оценке деятельности стратегической группы — это качество реализации проектов. На передний план выступают: тщательное предварительное проектирование, универсальность и масштабируемость, оформление и документирование. За соблюдение правил разработки проектов с этой группы — особый спрос. Размер премиального коэффициента за качество среди групп отдела программирования максимален. Дополнительный критерий

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

Второстепенный критерий

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

Задачи, оформляемые для этой группы в dotproject имеют низкий приоритет.


Catalyst. Perl web-фрэймворк. Руководство по эксплуатации. Основные принципы.

Gerda Shank, gerda.shank@gmail.com Kennedy Clark, hkclark@gmail.com

Основы Catalyst

Описание

В этой части руководства мы создадим очень простое web-приложение на основе Catalyst, демонстрирующее такие мощные инструменты как:

  • Вспомогательные скрипты, которые могут быть использованы для быстрого создания и настройки структуры приложения
  • MVC (Model/View/Controller), реализующий такую структуру, которая способствует качественному разделению функций между различными частями приложения. Существует множество документации, раскрывающей это определение в деталях, поэтому MVC не будем обсуждать его здесь подробно. В кратце:
    • Модель (Model) обычно отражает структуру данных. В большинстве приложений модель приравнивается к объектам, создаваемым и сохраняемым в вашей базе данных в виде SQL.
    • Вид (View) отображает объекты модели в удобной для пользователя форме. Обычно он создаёт html страницы для браузера на основе шаблонизаторов, но также может быть представлен в других формах, таких как PDF-документ или Excel-таблица
    • Контроллер (Controller), как видно из названия, контроллер позволяет пользователю получать и вызывать и обрабатывать необходимые представления и модели.
  • ORM — технология представления объектов-связей (Object-Relational Mapping) используется для доступа к БД. Фактически, ORM реализует стандартизированные и автоматизированные возможности по созданию и сохранению объектов в реляционной БД.

Инструкции о том, как можно получить исходный код с примерами из subversion репозитария catalyst можно найти в разделе «введение»

Создание проекта в Catalyst

В Catalyst есть несколько вспомогательных скриптов, которые позволяют быстро создать основную структуру вашего приложения. Все приложения в Catalyst создаются запуском вспомогательного скрипта catalyst.pl, для него, начиная с версии 5.7000, необходимо установить Catalyst::Runtime и Catalyst::Devel.

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

  $ catalyst.pl Hello
  created "Hello"
  created "Hello/script"
  created "Hello/lib"
  created "Hello/root"
  ...
  created "Hello/script/hello_create.pl"
  $ cd Hello

Далее показана структура каталогов, которую создаст вспомогателоьный скрипт catalyst.pl.

Changes # Запись об изменениях в приложении

  lib                   # Каталог для Perl-модулей
      Hello             # Каталог для кода приложений
          Controller    # Каталог для модулей контроллеров
          Model         # Каталог для моделей
          View          # Каталог для видов
      Hello.pm          # Основной модуль приложения
  Makefile.PL           # Makefile для сборки приложения
  hello.conf            # Файл конфигурации приложения
  README                # README file
  root                  # Подобный htdocs, каталог для шаблонов css, и javascript
      favicon.ico
      static            # Каталог для статичных файлов
          images        # Каталог для изображений, используемых в окне приветствия
  script                # Каталог для Perl-скриптов
      hello_cgi.pl      # Запустить приложение как CGI (не рекомендуется)
      hello_create.pl   # Создать модели, виды, контроллеры
      hello_fastcgi.pl  # Запустить приложение как fastcgi
      hello_server.pl   # Обычный сервер разработки
      hello_test.pl     # Тестирование приложения из командной строки
  t                     # Каталог для тестов
      01app.t           # Заготовки тестов
      02pod.t           
      03podcoverage.t

Catalyst будет автоматически создавать модули в каталогах ControllerModel, и View. Скрипт hello_create.pl позволит сделать в них заготовки Perl-модулей, плюс тестовые файлы в каталоге

t. По умолчанию шаблоны располагаются в каталоге root. Скрипты в каталоге script и их имена всегда нычинаются с названия вашего приложения в нижнем регистре. Если оно называется MaiTai, то созданные скрипты будут иметь вид maitai_create.pl

И хотя радоваться ещё пока рано, но у нас уже есть функционирующее приложение. Мы можем использовать скрипт, который нам предоставляет Catalyst, для запуска сервера разработки и просмотреть с помощью браузера страницу по умолчанию. Все скрипты в каталоге script могут быть запущены из основного каталога вашего приложения Hello.

Наберите следующую команду для запуска встроенного веб-сервера

$ script/hello_server.pl
[debug] Debug messages enabled
[debug] Loaded plugins:
.----------------------------------------------------------------------------.
| Catalyst::Plugin::ConfigLoader  0.17                                       |
| Catalyst::Plugin::Static::Simple  0.20                                     |
'----------------------------------------------------------------------------'

[debug] Loaded dispatcher "Catalyst::Dispatcher"
[debug] Loaded engine "Catalyst::Engine::HTTP"
[debug] Found home "/home/me/Hello"
[debug] Loaded Config "/home/me/Hello/hello.conf"
[debug] Loaded components:
.-----------------------------------------------------------------+----------.
| Class                                                           | Type     |
+-----------------------------------------------------------------+----------+
| Hello::Controller::Root                                         | instance |
'-----------------------------------------------------------------+----------'

[debug] Loaded Private actions:
.----------------------+--------------------------------------+--------------.
| Private              | Class                                | Method       |
+----------------------+--------------------------------------+--------------+
| /default             | Hello::Controller::Root              | default      |
| /end                 | Hello::Controller::Root              | end          |
'----------------------+--------------------------------------+--------------'

[info] Hello powered by Catalyst 5.7011
You can connect to your server at http://localhost:3000

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

[info] *** Request 1 (1.000/s) [10301] [Sun May 18 10:11:36 2008] ***
[debug] "GET" request for "/" from "127.0.0.1"
[info] Request took 0.017964s (55.667/s)
.----------------------------------------------------------------+-----------.
| Action                                                         | Time      |
+----------------------------------------------------------------+-----------+
| /default                                                       | 0.000540s |
| /end                                                           | 0.001246s |
'----------------------------------------------------------------+-----------'

Нажмите Ctrl+C, чтобы остановить сервер разработки.

Hello, world

Простейший путь

Контроллер Root.pm является местом, где описываются действия, выполняемые, как правило, из корневого URL. Откройте файл lib/Hello/Controller/Root.pm в любом текстовом редакторе. Вы увидите функцию default, которая отвечает за отображение страницы-приглашения, которую ранее видели в браузере. Позже, возможно будет желание сменить её на что-то более полезное, например сообщение о 404-й ошибке. Но пока оставьте её в таком виде.

sub default :Path :Args {
    my ( $self, $c ) = @_;

    $c->response->body( $c->welcome_message );
}

$c в данном контексте — ссылка для доступа к Catalyst-приложению. Дополнительно она предоставляет доступ к объектам response и request (см. Catalyst,Catalyst::Response, и Catalyst::Request).

$c→response→body определяет содержимое HTTP ответа, а

$c→welcome_message — специальный метод(обработчик), возвращающий сообщение-приглашение, которое вы уже видели в браузере.

:Path :Args после имени метода — это аттрибуты, определяющие какие URL будут обрабатываться этим методом(обработчиком)(в зависимости от вашей версии Catalyst может быть использован «Private», но лучше этого не делать).

Некоторые MVC фрейворки управляют обработкой URL из одного места. Политика Catalyst такова, что управление обработкой URL осуществляется обработчиками внутри контроллеров. Это даёт гибкость в определении соответствия URL и обработчика. Обработчик default будет вызываться для всех URL, потому что не определён путь (ничего не указано после Path), и будет принимать любое количество аргументов (ничего не указано после Args).

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

Например, URL /admin/articles/create обрабатывается Hello::Controller::Admin::Articles, и обработчиком create внутри него.

Добавьте следующий обработчик в libs/Hello/Controller/Root.pm:

sub hello : Global { my ( $self, $c ) = @_; $c→response→body(«Hello, World!»); }

В данном примере вы посылаете в браузер свою собственную строку.

Сохраните файл, перезапустите сервер разработки и проследуйте на http://localhost:3000/hello, чтобы увидеть «Hello, World!».

Hello, World! с использованием вида и шаблона

В понятиях Catalyst «ВИД» — это не не XHTML — страница или или шаблон для представления в браузере. Это модуль, определяющий тип вывода — HTML, pdf, XML.

Чтобы создать TT-вид, запустите

$ script/hello_create.pl view TT TT

Будет создан модуль lib/Hello/View/TT.pm, который является дочерним классом Catalyst::View::TT. Ключевое слово view говорит скрипту, что мы создаём вид. Первое TT, что что вид будет на основе ToolkitTemplate шаблонизатора, а второе TT, что имя у модуля вида будет TT.pm(он будет использован для всех видов TT, и вы можете назвать его как хотите, например HTML.pm). Если посмотрите внутрь него, то обнаружите только настройки в виде константы, определяющей, что расширение для TT — это .tt

Теперь, когда вид «TT.pm» существует, Catalyst автоматически обнаружит его и позволить использовать его для отображения шаблонов, используя метод

«process»

Template Toolkit — прекрасно документированный (http://template-tookit.org), мощный шаблонизатор, но поскольку это не документация по TT, мы рассмотрим лишь некоторые его основные возможности.

Создайте файл шаблона root/hello.tt (Разместите в подкаталоге root каталога приложения Hello). Вот простой пример:

  [% META title = 'Hello, World!' %]
  <p>
      This is a TT view template, located in the 'root/' directory.
  </p>

[% and %] — маркеры частей TT — шаблона. Внутри них вы можете получить доступ к переменным и классам Perl, а так же использовать директивы TT. За пределами маркеров шаблон представляет из себя самый обычный HTML. Замените обработчик hello в lib/Hello/Controller/Root.pm следующим:

  sub hello : Global {
      my ( $self, $c ) = @_;

      $c->stash->{template} = 'hello.tt';
  }

В этот раз, вмето того, чтобы использовать $c→response-body(), устанавите значения ключа template хэша stash. В этот хэш помещаются данные, которые должны быть видны в других частях приложения. Ключ template определяет какой шаблон должен использоваться для отображения в конце обработчика.У контроллеров Catalist для всех обработчиков есть действие по умолчанию «end», которое выполняется при формировании страницы если нет оператора $c→response→body(). Таким образом ваш шаблон будет отображен при окончании работы вашего обработчика.

Сохраните lib/Hello/Controller/Root.pm и перезапустите сервер разработки, и снова взгляните на http://localhost:3000/hello. Вы должны увидеть результат применения шаблона.

Создание простого контроллера и действия

Создайте контроллер с именем «Site» выполнив

$ script/hello_create.pl controller Site

Будет создан файл lib/Hello/Controller/Site.pm (и тестовый файл). Добавьте туда обработчик

sub test : Local {
    my ( $self, $c ) = @_;

    $c->stash->{username} = "John";
    $c->stash->{template} = 'site/test.tt';
}

Обратите внимание на аттрибут Local у этого обработчика. Это позволяет ему отрабатывать URL вида «контроллер/обработчик», в нашем случае «site/test» вместо корневого URL, как при «Global». Имя шаблона указывать необязательно, поскольку TT по умолчанию будет пытаться использовать шаблон следующего вида «контроллер/обработчик.tt», но возможны ситуации, когда вам необходимо определить своё (например ещё неизвестно имя обработчика, или если не соблюдается трансляция имён по умолчанию). Так же в stash вставим ключ «username» для использования в шаблоне.

Создайте подкаталог site в каталоге root. Скопируйте

hello.tt как root/site/test.tt. Включите туда строку

<p>Hello, [% username %]!</p>

Перезапустите сервер разработки и проследуйте по адресу http://localhost:3000/site/test. Вы должны увидеть интерпретированный файл test.tt, включая установленное контроллером имя John.