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

Данная идея встречает различный спектр преград. Начиная от того, что не приходит письмо об регистрации на e-mail, заканчивая крылатым выражением “зачем нам играть в тудушки?”.

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

Некоторые люди (в том числе и я) на больших проектах используют баг трекер, чтобы “стучать” друг на друга. И даже не из-за конкуренции, хотя и она немаловажна, а больше для того, чтобы намекнуть вышестоящим о том, что товарищ ленится по тем или иным причинам и тормозит процесс. Согласитесь, что это значительно удобнее в моральном плане, нежели идти и жаловаться. Тут и совесть чиста и есть шанс, на то что ситуация изменится в лучшую сторону.

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

1. Вся документация, пароли и прочее хранятся в одном месте, вместо тучи файлов.
2. Баг трекер позволяет структурировать задачи по категориям и наглядно их отобразить, вместо того чтобы писать какие-то задачки на листочках и раздавать сотрудникам.
3. Нет необходимости тратить время на встречи и обсуждения текущих дел, сроков, так как достаточно проанализировать количество закрытых / открытых заданий, посмотреть на milestone.
4. Любые недовольства высказываются в комментарии, которые всегда (или практически) открыты.
5. Является отличным документом, который может встать на защиту Вашей правоты, а так же избавить от уймы рутинной работы.

1142 – INSERT command denied to user ‘abc’@'host.com’ for table ‘billing’

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

В CodeIgniter мультиязычность реализована довольно таки просто.
В папки application/language создается папка с нужным языком (если их будет несколько), например russian и туда кладется php файл с массивом соответствий. Например вот так

Чтобы перевести ту или иную строку должна быть подгружена библиотека language и соответствующий массив с языковыми значениями. Чтобы не писать длинную строку вида $this->lang->line('some_key') я предпочитаю использовать функцию lang(); хэлпера language.

Теперь от теории к практике!
Делая бэкенд веб-сайта BasaPress перед мной встала задача динамически менять язык при отправке того или иного письма.
К моему удивлению действия в виде $this->lang->load(filename, language); перед тем как отработает шаблон письма ничего не давали.
Погуглив немного можно наткнуться на всякие различные i18n модули, библиотеки и прочие фичи, которые расширяют функционал. Но загвоздка в том, что меня устраивает как работает CI, загвоздка лишь в том, что он не хочет подгружать язык в определенном участке кода.

Взглянув на метод load класса CI_Lang сразу становится ясно в чем дело

if (in_array($langfile, $this->is_loaded, TRUE))
{
return;
}

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

К счастью все правится довольно просто и быстро.
В случае с CodeIgniter 2.0 библиотека lang лежит в папке system/core. Нам необходимо переопределить метод load(). Для этого создадим файл в application/core MY_Lang.php
Далее, все что нужно – унаследовать класс CI_Lang

class MY_Lang extends CI_Lang
{
…
}

и скопировать внутрь полностью метод load().

После чего немного поправим код вот таким образом.

if (in_array($langfile, $this->is_loaded, TRUE) && !$idiom)
{
return;
}

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

На этом пожалуй все, успехов!

Выкладываю на общий суд.

Ничего особенного в запуске данной библиотеки нет.
Копируем tagcloud.php в папку %APPLICATION_PATH%/libraries, подгружаем библиотеку

$this->load->library(‘tagcloud’);

Далее, чтобы получить облако тегов необходимо передать массив с title тега, его url и count (count – это количество фильмов с этой категорией, к примеру).

$links = array(
array(‘title’ => ‘Action’, ‘url’ => ‘google.com’, ‘count’ => 15),
array(‘title’ => ‘Thriller’, ‘url’ => ‘http://yandex.com’, ‘count’ => 235),
array(‘title’ => ‘Comedy’, ‘url’ => ‘http://www.google.com’, ‘count’ => 46),
array(‘title’ => ‘Animation’, ‘url’ => ‘animation’, ‘count’ => 56),
);

echo $this->tagcloud->getTagcloud($links);

Обращаю внимание, что url не содержащих http считается внутренним. т.е. sitename.com/google.com

По умолчанию шрифты варьируются от 9 до 18, но при помощи конфигов можно задать их как угодно. Так же для для линков можно прописать собственный класс (по умолчанию tagcloud)

$config = array(
‘min_size’ => 12,
‘max_size’ => 36,
‘class’ => ‘mytagclass’
);
$this->tagcloud->initialize($config);

или же можно конфиг передать сразу при подгрузке библиотеки

$this->load->library(‘tagcloud’, $config);

Скачать библиотеку можно отсюда