Сегодня 16 сентября, вторник ГлавнаяНовостиО проектеЛичный кабинетПомощьКонтакты Сделать стартовойКарта сайтаНаписать администрации
Поиск по сайту
 
Ваше мнение
Какой рейтинг вас больше интересует?
 
 
 
 
 
Проголосовало: 7281
Кнопка
BlogRider.ru - Каталог блогов Рунета
получить код
Хабрахабр: PHP / Блог / Захабренные
Хабрахабр: PHP / Блог / Захабренные
Голосов: 1
Адрес блога: http://habrahabr.ru/blog/php/
Добавлен: 2008-06-12 19:52:35 блограйдером ZaiSL
 

Реализация быстрого импорта из Excel на PHP

2014-05-29 11:34:35 (читать в оригинале)


Мы продолжаем рассказывать о технологиях, используемых на нашем сервисе email-маркетинга Pechkin-mail.ru. Одной из ключевых задач любого сервиса, связанного с данными клиентов, является загрузка этих данных на сервис. Для Печкина очень важно быстро и без проблем для пользователя загружать адресные базы, содержащие email-адреса, имена, фамилии и другие дополнительные данные.

Что использовать в качестве инструмента?


В качестве базового стандарта, используемого при импорте адресных баз, мы взяли Microsoft Excel. Объясняется это просто:
  • это стандартный инструмент, которым на базовом уровне владеют 100% пользователей компьютеров. Более того, в бизнесе — это де-факто корпоративный стандарт и используется даже, если на рабочих компьютерах Mac или Linux.
  • Практически все CRM-, CMS-, облачные или десктопные системы имеют экспорт в Excel или CSV, который простым пересохранением приводится к формату XLS или XLSX.
  • Известно также, что “90% ошибок ПО сидит в полуметре от монитора”. Не в обиду будет сказано рядовым пользователям, но мы должны учитывать самый базовый уровень подготовки и тех. поддержке для объяснения достаточно сказать “Загрузите Excel-файл”, а не объяснять процедуру подготовки файла в нужном формате.


Проблему пользователей при импорте адресных баз сняли. Но тут возникает уже проблема непосредственно разработки.
Прочитать о быстрой реализации импорта из Excel на PHP и LibXL

[Из песочницы] Введение в JadePHP

2014-05-29 02:58:49 (читать в оригинале)


По предложению автора интересностей и полезностей для веб-разработчика #17, предлагаю свой перевод статьи Introduction to JadePHP.

Существуют десятки шаблонизаторов. Среди наиболее известных можно выделить Smarty, Twig (используется в следующей версии Drupal), Blade (используется по умолчанию в Laravel) и, конечно же, vanilla PHP. Если не говорить конкретно о PHP, то для eRuby / ERB и Haml для Ruby / Ruby on Rails и Javascript есть ряд популярных вариантов, как например Mustache, Handlebars, Hogan и EJS. У одних различия в синтаксисе незначительные, у других они более выраженные.

Шаблонизатор Jade, который значительно отличяется от других, обычно ассоциируется с JavaScript приложениями, например он поддерживается в Express для Node.js. В этой статье, я поговорю о Jade или, более конкретно, о Jade сделанной для PHP — JadePHP.
Читать дальше →

[Перевод] Отладка электронной почты при помощи MailCatcher

2014-05-28 22:47:14 (читать в оригинале)


imageВы используете в своем приложении электронную почту, не так ли? Это, в общем-то, риторический вопрос, конечно используете. Ей уже больше 30 лет, а это по прежнему самое популярное средство коммуникации на планете. Вот некоторые статистические данные от Pingdom:
  • 2,2 млрд. — Количество пользователей электронной почты по всему миру
  • 144 млрд.- Объем отправляемых электронных писем ежедневно во всем мире
  • 4,3 млрд.- Количество почтовых клиентов во всем мире

Потрясающе!

Зачем нужна эта статья?


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

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

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

Было такое? Не хочется, чтобы повторилось? Есть решение — MailCatcher. Если вы не слышали о нем то вкратце:
… Супер-простой SMTP-сервер, который перехватывает любое отправленное сообщение и выводит его в веб-интерфейсе. Запустите mailcatcher, в настройках вашего приложения укажите smtp://127.0.0.1:1025 вместо SMTP-сервера по умолчанию, и затем просматривайте почту, которая была отправлена по адресу http://127.0.0.1:1080


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

Сейчас я хочу показать вам, как настроить, запустить и использовать MailCatcher.
Ну-ка, поглядим...

Опасный getimagesize() или Zip Bomb для PHP

2014-05-28 08:46:33 (читать в оригинале)


Рекурсия

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

«Отлично, — подумал я, — самое время поковырять какой-нибудь движок, пока оно не вернулось!»

Сказано — сделано. Под катом предлагаю небольшой обзор уязвимости в распространённом движке фото-галереи на PHP и о том, как можно положить любой сайт, использующий getimagesize(), с помощью бородатой zip-бомбы (или пета-бомбы).
А что там дальше, за рамкой-то?

[Из песочницы] RESTful API на Yii framework с RBAC и тестами

2014-05-27 00:00:03 (читать в оригинале)


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

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

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

  1. Одна из первых проблем с которой я столкнулся — сохранение различных сущностей в одной таблице. Для получения таких записей уже не достаточно просто указать имя модели как это предлагается, например тут. Один из примеров такого механизма — таблица AuthItems, которая используется фреймворком в механизме RBAC (если кто-то не знаком с ним — есть замечательная статья на эту тему). В ней содержатся роли, операции и задачи которые определяются флагом type, и для работы с этими сущностями через API мне хотелось использовать url не такого типа:
    GET: /api/authitems/?type=0 - получение списка операций
    GET: /api/authitems/?type=1 - получение списка задач
    GET: /api/authitems/?type=2 - получение списка ролей

    а такого:
    GET: /api/operations - получение списка операций
    GET: /api/tasks - получение списка задач
    GET: /api/roles - получение списка ролей

    Согласитесь, второй вариант выглядит очевиднее и понятнее, тем более для человека не знакомого с фрейморком и устройством RBAC в нем.
  2. Вторая немаловажная возможность — механизм поиска и фильтрации данных, с возможностью задавать условия и комбинировать правила. Например, мне хотелось иметь возможность выполнить аналог такого запроса:
    SELECT * FROM users WHERE (age>25 AND first_name LIKE '%alex%') OR (last_name='shepard');
    

  3. Порой не хватает возможности создания, обновления, удаления коллекций. Т.е. изменение n-ого количества записей одним запросом опять же используя поиск и фильтрацию. Например, зачастую требуется удалить или обновить все записи, попадающие под какое-либо условие, а использовать отдельные запросы слишком накладно.
  4. Еще одним важным моментом была возможность получать связанные данные. Например: получить данные роли вместе со всеми её задачами и операциями.
  5. Конечно невозможно хоть сколько-нибудь комфортно работать с API не имея возможности ограничить количество получаемых записей (limit), сместить начало выборки (offset), и указать порядок сортировки записей (order by). Так же не плохо бы иметь возможность группировки (group by).
  6. Важно иметь возможность для каждой из операций проверять права пользователя (метод checkAccess все в том же RBAC).
  7. Ну и наконец, все это дело нужно как-то тестировать.

В результате анализа примерно такого списка «хотелок» и появился на свет мой вариант реализации API на этом замечательном фреймворке!
Читать дальше →


Страницы: ... 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 ... 

 


Самый-самый блог
Блогер ЖЖ все стерпит
ЖЖ все стерпит
по сумме баллов (758) в категории «Истории»
Изменения рейтинга
Категория «Спорт»
Взлеты Топ 5
+310
316
Мой журнальчик
+301
320
sib's Blog
+276
289
Media_Sapiens
+275
293
McMurphy
+273
278
sich
Падения Топ 5


Загрузка...Загрузка...
BlogRider.ru не имеет отношения к публикуемым в записях блогов материалам. Все записи
взяты из открытых общедоступных источников и являются собственностью их авторов.