«…Почему? Кто поймет? В самом деле, почему мед так нравится ему?»
Одна нехитрая задачка (про мед и деготь), и один столь же нехитрый алгоритм. Пост рекомендуется для соискателей вакансии программиста, а так же для тех, кому скучно и не до конца понятно при чем тут мишка.
Возникла в ходе работы такая несложная задача - «организация общения xml-сообщениями».
SOAP слишком затратно. Для чтения данных из xml-сообщения сначала было решено конвертировать xml-файл в многомерный массив PHP и последующей передачей данных по ключам в этом массиве. Для обратного процесса, соответственно, генерация правильно сформированного многомерного массива и перегон в xml-строку. Среди явных плюсов данного подхода имеется быстрота и миллионы «велосипедов» для конвертации. Среди минусов – чрезмерное количество проверок на существование значения для нужной переменной в этой структуре при чтении xml-сообщения и неповоротливые куски кода по компоновке соответствующего многомерного массива при генерации xml-сообщения.
Собственно, наплевав на выбор между хреном и редькой, так и было сделано. Потом, спустя время, что-то подсказывало, что есть более изящное решение. Память и мануалы подсказали, что можно использовать для этих целей DOMDocument и DOMXPath.
Итак. Две простейшая задачи: получить из XML-документа данные и сформировать из данных xml-документ.
Делаю проект на Symfony 1.4 с публичной частью и системой управления. Чтобы не изобретать велосипед, в качестве учетной системы пользователей решил использовать sfDoctrineGuardPlugin — плагин существует давно, и является весьма мощным в функциональном плане.
Описание установки и последующей кастомизации смотрите под катом.
В Netcat штатные компоненты для работы с фотографиями производят довольно унылое впечатление. Не совсем понятно, почему разработчики CMS отказываются от использования сторонних библиотек, той же Lightbox2, например. Встраивается элементарно, а смотрится это дело ни в пример лучше.
Что ж, если в поставке системы нет приличного фотоальбома, давайте сделаем его сами.
3 июля 2010 года в Киеве состоялась конференция Symfony Camp UA, на которой я выступил с докладом «Перевод боевого сайта с ветки 1.0 на ветку 1.4».
Материалом для доклада послужила реальная задача, выполненная нами для одного из заказчиков. Актуальность перехода на ветку 1.4 довольно высока, так как на момент проведения конференции официальная техническая поддержка ветки 1.0 была прекращена (в январе 2010 года), а поддержка веток 1.1 и 1.2 была прекращена еще раньше — в июне и ноябре 2009 года соответственно.
Впечатления от конференции самые положительные. Continue reading
Если кто не смотрел «День радио», настоятельно рекомендую. Лучше спектакль, чем фильм, и то, и другое в сети доступно. Но предпочтительнее, конечно, в зале, очень смешно.
При чем тут День радио? Да просто так. К вопросу о стиле командной работы.
Диспозиция: заказчик в Америке. До этого колесил по Азии и был в интернетах не доступен. Пара недель отставания от графика. И вот, заказчик проявляется и задает сакральный вопрос – как дела, собственно? Разговор с «Михаилом Гедеоновичем».
И далее, уже скайпе, для своих:
«Значит так. Я выкрутился. Теперь – ваша очередь!»
Можно было бы назвать этот пост как-нибудь по-научному… Скажем, использование принципа наследования при построении иерархических каталогов.
Адаптер – программный механизм, который обеспечивает синхронизацию сайта с внутренней учетной системой предприятия.
Это не из Википедии, это мы сами придумали.
Собственно, базовый функционал был разработан нами еще в 2003 году.
Заказчик: НПК Контакт. Задача формулировалась следующим образом. Есть учетная система предприятия (не 1С). Из нее нужно получить бизнес-данные, обработать их определенным образом, дополнить маркетинговыми данными и транслировать на сайт. Кроме того, нужно организовать и обратный процесс – трансляцию в учетную систему данных из внешнего мира (курсы валют, данные пользователей и т.д.).
Заказчик желает веб-систему. Пишем ФТ, ТЗ, программируем, тестируем, размещаем, даем гарантии. Все хорошо. Но по истечении гарантийного срока что-то ломается. Причем, в части, наиболее критичной в аспекте бизнес-логики.
Заказчик сетует и обращается за помощью. Программист недоумевает, исправляет. Потом снова. Потом еще. Симптомы немного разнятся, но модуль всегда один и тот же.
Заказчик начинает, мягко говоря, нервничать.
Программист начинает, мягко говоря, нервничать.
Руководитель проекта нервничает больше всех, и настаивает на том, чтобы заказчик перешел в режим коммерческой техподдержки.
Я, вняв, пишу заказчику соответствующее предложение.
От этого предложения заказчик нервничает пуще программиста и ПМ’а, вместе взятых. Ему не нужна техподдержка, ему нужно решить только Одну проблему. Одну. Но – решить.
В итоге, выясняется, что беда в некорректных пользовательских данных. От этого модуль начинает периодически глючить. Вот, идиотизм-то, а! И вроде даже кто-то кому-то что-то где-то объяснял…
Заказчик требует (и получает) реквизиты суперадмина, будучи в полной уверенности, что проблемы мы создавали искусственно, дабы получить контракт на техподдержку.
Мораль до слез банальна, аж стыдно. Проверяйте на валидность данные, введенные пользователем. Всегда.
Дизайн в интернете – это большой мыльный пузырь, его значимость чрезмерно завышена. И надувают его, вольно или не вольно, те, кто в этом лично заинтересован. Это всегда, в ста процентах случаев, борьба либо за деньги, либо за влияние (в любом масштабе: отрасли, предприятия или рабочей группы). Все эти «не выстроены визуальные коммуникации», «этот сайт – унылое гавно», «нам не нужны шаблонные решения», «акцент определяется не тоном, а насыщенностью» – все это от лукавого. Это либо вранье, либо безграмотность.
Возможно странно так поступать, но сложно удержаться.
Отличная фраза, найденная на одном отличном сайте:
«Наша цель – предоставить решения, которые подходят Вашему бизнесу, а не подгонять Ваше деловые процессы к нашим решениям».
Классно. Большинство поступает строго наоборот, стараясь сформировать потребности под свои чудо-продукты. Тоже, впрочем, не бедные ребята.
