xelbot.com

Что-то довольно часто стала попадаться на глаза эта система комментариев, т.е. DISQUS. Любопытство взяло вверх, решил посмотреть, как оно всё выглядит изнутри, а этот блог как раз подходит на роль площадки для всяческих испытаний :)

Оказалось даже проще, чем я себе это изначально представлял, думал, что может приключиться что-то со стилями CSS и прочим, но ничего не произошло. Короче говоря, установить его сможет и домохозяйка, для которой html и javascript не пустой звук. Хотя если учитывать существование плагинов под WordPress, Blogger или Tumblr, то и эти условия становятся необязательными.

Комментарии, конечно, не посыпятся сюда, как из ведра, но надеюсь, что потратил своё драгоценнейшее время не зря :) А запись пусть висит тут для истории.

Запустил недавно магазинчик на базе популярного движка Magento. Хотя знатоки увидят это уже по favicon, менять его не стал :)

Хоть помещаю эту запись в раздел "Работа", но с той работой, где находятся мои работо- и зарплатодатели, данная новость никак не связана, это, скорее, фриланс, но не пропадать же категории.

Иногда возникает потребность выводить дату в таком формате, когда месяц написан текстом, но при этом сайт многоязычный. Месяц, естественно, тоже должен соответствовать выбранной локали. Вот тут и возникает загвоздка, поскольку php-шная функция date выведет месяца на английском. Какой-нибудь крутокодер Вова Теплов создал бы массивчик с переведёнными месяцами и прошёлся бы простой заменой, поскольку некогда разбираться, надо делать тикеты. Но это не наш путь. Языков на сайте может оказаться пять штук, один из которых, допустим, арабский/корейский. Да и сами языки могут добавляться на сайт в будущем.

В общем, задача эта типовая и не надо ничего придумывать. Решение имеется уже готовое → IntlDateFormatter. Но решать эту задачу я буду в контексте Symfony 2.

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

Собственно, вылазит ошибка вида:

1
2

[Composer\Downloader\TransportException]
The "https://api.github.com/repos/bla-bla-bla/zipball/v6.6.6" file could not be downloaded (HTTP/1.1 404 Not Found)

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

1

php composer.phar install --prefer-source

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

Живу себе спокойно, никого не трогаю, а мой блог этот, как оказалось, регулярно проверяют на вшивость. Часть вторая, так как первая находится → тут, но там дело касалось спама.

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

Не в первом проекте уже сталкиваюсь с ситуацией, когда при импорте данных при помощи ORM Doctrine 2 происходит падение производительности с увеличением количества импортируемых данных. Вот и сейчас проявилась данная особенность, а заодно и обнаружилось решение, которым спешу поделиться :)

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

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

Вывешу скриншот из серии БЫЛО и СТАЛО, остальное под катом...

Такого вот чудика встретили во время прогулки.

Не смог пройти мимо и не сфотографировать :) Жалко, что аккумулятор смартфона разрядился к тому времени, не удалось зафиксировать гео-метку, пришлось снимать на старый телефон (которому батареи всё же хватает больше, чем на день). Ну да ладно, это всё ерунда, главное, что чудик уже в интернетах. Хотя он вполне мог туда уже попасть сотню раз и без моего участия.

Ниже ещё несколько фоток, да и разрешение повыше.

Допустим, что вы используете ORM Doctrine 2 и что вам необходимо выбрать из базы некие записи, но не просто так, а по хитрому. Выборка должна осуществляться по хешу какого-то поля, значение в котором вы не хотите никому показывать из соображений безопасности. Пример, возможно, и надуманный, но не в этом суть... Короче говоря, нужно реализовать подобный запрос:

1
2

SELECT * FROM `spam` AS `s`
WHERE MD5(`s`.`secretfield`) = 'hash';

Дальнейшие действия хоть и касаются DQL и Doctrine, но будут описаны в контексте фреймворка Symfony 2. Оригинальную статью можно обнаружить в документации