Ну про Zend сертификацию PHP 5.3 никто еще не писал, попробую написать я, надеюсь, будет интересно.

План будет таков: сначала я расскажу зачем, потом о подготовке и о сдаче экзамена.

Приступим!

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

Часто можно услышать мнение, что в России аутсорсинг не прижился и является столь же редким явлением, как и амурские тигры. Причин называется много: и боязнь «слить» свою информацию малоизвестным третьим лицам, и малое предложение таких услуг (как следствие – высокая цена), и недостаточно высокое качество. Среди причин часто упоминают невозможность наорать матом на находящегося на аутсорсинге исполнителя и заставить его работать сверхурочно до 23 часов без доплаты, только потому, что «так надо». То же и с безопасностью – «своего» сотрудника может припугнуть собственная служба безопасности так, что он не только сам не продаст никакой информации конкуренту, но и сдаст в СБ своих коллег, которые уже это сделали.

В этой статье я закончу свой рассказ о разработке моей первой игры под Android. Для тех, кто не видел/не прочел — часть первая.

Добрый день, коллеги! На Хабре достаточно часто появляются посты про разработку первых Android-приложений, и я решил также поделиться своим опытом. Это мой первый писательский опыт на Хабре и моя первая игра, поэтому прошу строго не судить.

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

Любой приказ, который может быть неправильно понят, понимается неправильно (Армейская аксиома)

Редкий скрипт лишен необходимости общения с пользователем. Мы ожидаем, что программа (утилита) будет выполнять то, что нам от нее хочется. Следовательно, нужны инструменты влияния на них, да и программа сама должна объяснить, как продвигается ее работа.
Данным топиком я хочу рассмотреть несколько способов взаимодействия bash-скриптов с пользователем. Статья рассчитана на новичков в скриптинге, но, надеюсь, люди опытные тоже найдут что-нибудь интересное для себя.

Зачем терять время на разговоры о качестве?

Вам нужно в короткие сроки запустить веб-проект, вы выбираете платформу Битрикс или другой фреймворк, подрядчика/интегратора (либо делаете силами собственных программистов), делаете веб-сайт и в час X посетители начинают пользоваться веб-решением.
Зачем отвлекаться на вопросы качества интеграции, если веб-проект запущен и цель, казалось бы, достигнута? Сайт доступен для клиентов, проект реализован почти в срок и уложился в бюджет, премии получены… :-)
Многие просто не задумываются о дальнейшем развитии веб-проекта. А некоторые категории менеджеров откровенно преследуют цель запустить веб-решение в срок и им попросту «наплевать» на качество и дальнейшую судьбу веб-сайта (проект можно попросту передать другому менеджеру).

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

1) Кэширование результатов выполнения запросов

• плюсы: высокая скорость доступа к данным
• минусы: требует компромисса между актуальностью данных и скоростью доступа, т.к. данные в кэше могут устареть, а удалять старые данные из кэша с последующим кэшированием новых — это дополнительные задержки и нагрузка на систему

2) NoSQL решения

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

Сегодня я хочу познакомить вас с таким типом хранилища данных, который объединяет достоинства обоих подходов и при этом имеет ряд преимуществ перед упомянутыми выше решениями: In-memory-data-grid (IMDG).

Хочу поделиться рецептом, как совместить php-скрипт и почтовый сервер Postfix для автоматической обработки входящей почты.

С помощью такой связки мы собираем статистику по количеству возвратов bounce-писем:Undelivered Mail Returned to Sender.

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

Вступление

Привет хабровчане,

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

• Сделает работу верстальщика немного проще и чище
• Упростит выборку элементов на странице через популярные платформы, аля jQuery

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

Дальше — больше. Читаем?

Давно уже взял себе за правило вносить все изменения на сайт через код. Теперь добрался и до панелей (модуль panels).
Если необходимо импортировать большое количество панелей то можно воспользоваться модулем features. Единственное что не удобно, так это то что этот модуль экспортирует все панели в один файл, и потом с этим файлом довольно-таки сложно работать.

На много удобнее иметь некую папку import/ и складывать туда панели, каждый в своем файле. В этом случае, при необходимости, очень просто редактировать любые панели, а также прослеживать изменения (если вы конечно используете систему контроля версий, такие как SVN или GIT).

Ничего подобно я найти не смог, поэтому написал свой маленький модуль с блэкджеком и импортом.

В некоторых случаях абсолютно бессмысленно и неоправданно нагружать как клиентскую часть веб-приложения, так и серверную. Чтобы не ходить долго вокруг да около, приведу пример из жизни. От разработчика мне достался один интернет-магазин, в котором работа с корзиной происходила следующим образом. При клике на кнопку добавления товара в cookie сохранялись ID товара и его количество. Соответственно, чтобы при посещении различных страниц пользователю показывалось, что находится в корзине, в каком количестве, сколько это добро стоит и прочие данные, серверному приложению приходилось выполнять следующие функции:

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

Все вроде бы и ничего. Я думаю, многие с подобными схемами сталкивались и не раз. Но передо мной стояла задача оптимизации приложения, и я решил убрать среди прочего лишнюю нагрузку с сервера путем устранения как запросов в БД, так и генерацией блока корзины. Хотелось бы хранить все данные о выбранных товарах на стороне клиента. Причем, в идеале хотелось хранить не только массив выбранных товаров, но и уже готовый HTML-код блока корзины, кроме того, таблицу с товарами для страницы оформления заказа. Но как это сделать?

Здравствуйте.

Хотел поделиться с широким читателем информацией о реализации Friendly URL на своих проектах.

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

Наверняка, когда перевод на четвёртую версию движка закончат для всех клиентов, здесь на Хабре сделают про это топик, а в преддверии хочу поделиться с вами тем, до чего докатился в плане управления задачами в Codebase за пару лет его использования. Это будет актуально для любой версии.

Настроение философско-лирическое, поэтому вместо того, чтобы работать, потянуло поразмышлять, на сколько правильно реализована система прав в CMS Bitrix и как бы это сделал я.

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

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

Три типа данных: «объект», «операция над объектом», «право на операцию».

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

Что делает приложение

[к] — клиент
[c] — сервер
1. По установленному TCP соединению, [к] передает публичный ключ rsa.
2. При помощи принятого публичного ключа, [c] шифрует и отправляет сообщения [к]
3. [к] расшифровывает и выводит сообщения.

Вот как это выглядит в консоли:

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

   <div id="block_outer">
      <div id="block_inner"></div>
   </div>

А теперь представьте, что к блоку #block_outer привязано событие onClickOuter, а к блоку #block_inner, соответственно, событие onClickInner. И ответьте на вопрос, как сделать так, чтобы при клике на блок #block_inner, событие onClickOuter не вызывалось? И будет ли оно вообще вызвано? И если будет, то в каком порядке события будут вызываться? И знаете ли вы, как работает метод jQuery.live или подобные в других библиотеках (events delegation в ExtJS, например)?

Обычно программисты используют технологии по прямому назначению, но я решил провести эксперимент и попробовать использовать сервер memcached как масштабируемое временное key=value хранилище.
Memcached предназначен для простого кэширования статических данных, потому в нем не предусмотрена система избежания коллизий.

Запись данных

Стандартная ситуация

Предположим, что наше PHP приложение работает на одном сервере, а memcached работает на удаленной машине. Мы без проблем сможем читать и писать в одну и ту же ячейку, потому как приложение не WEB, так что процесс один. Из-за линейности процесса, ему не удастся одновременно записывать разные данные в одну и ту же ячейку.

Два и более процесса

Сегодня нам понадобилось разделить приложение на два сервера и начались проблемы. Возникли коллизии при записи в memcache. Выяснилось, что в 80% случаев приложения пытаются одновременно записать свои данные в одну ячейку. Идеальным решением было бы использование shared memory, но она не масштабируется в отличие о Memcached. В связи с большим объемом кода и предполагаемым временем на переписывание приложений, было принято решение добавить костыль.

Nodeload, первому проекту команды GitHub, выполненному с использованием node.js, недавно исполнился 1 год. Nodeload, — это тот сервис, который упаковывает содержимое Git-репозитория в ZIP-архивы и тарболы. С тех пор нагрузка на сервис росла в течение года, и мы столкнулись с различными проблемами. Почитайте о происхождении Nodeload, если вы не помните, почему это работает так, как работает сейчас.

По существу, у нас стало слишком много запросов, проходящих через один сервер nodeload. Эти запросы запускали процессы git archive, которые запускали SSH-процессы для общения с файловыми серверами. Эти запросы постоянно записывали гигабайты данных, а также передавали их через nginx. Одной простой идеей было заказать больше серверов, но это создало бы дубликат кэша заархивированных репозиториев. Я хотел избежать этого, если возможно. Итак, я решил начать все сначала и переписать Nodeload с нуля.

0. Intro.

В процессе разработки достаточно часто нужно использовать различные кастомные селекты, инпуты, загрузщики файлов и прочее. В этом случае приходится писать дополнительные обработчики на стороне клиента, так как ZF из коробки не знает ничего, кроме стандартных элементов форм (капча есть исключение). В этой статье будет рассмотрено создание элемента на базе facebook-like TextboxList плагина для jQuery, который выглядит вот так:

Единственный интуитивно-понятный интерфейс — это женская грудь, всему остальному нужно учиться. Эта народная мудрость пришла ко мне сегодня утром, когда я в деталях и красках рассказывал третьему по счету коллеге, чем resolved отличается от closed и как делать log work, чтобы руководству не было потом мучительно больно. В этой статье я попробую на примере нескольких зарисовок обрисовать возможные варианты использования системы управления задачами на примере популярной Jira при ежедневной работе. Приемы, конечно, не единственно возможные — но они достаточно просты, универсальны и применимы не только к Jira, но и к большинству популярных систем управления задачами — Redmine, Trac, Bugzilla и прочим.