На днях я столкнулся с очень интересной проблемой. В системе, с которой я разбирался, использовался механизм ограничения времени жизни сессии. Валидация этого времени перекладывалась на плечи garbage collector'а, который почему-то её выполнял не совсем добросовестно, а то и вовсе не выполнял. Как оказалось, ошибки эти общераспространенных, по этому о тонкостях работы с GC я и хотел бы рассказать.

В php за работу GC для сессий отвечают 3 параметра: session.gc_probability, session.gc_divisor и session.gc_maxlifetime.
Эти параметры говорят о следующем: в gc_probability из gc_divisor запусков session_start запускается GC, который должен очистить сессии со временем последнего обращения больше, чем gc_maxlifetime.

Добрый день хабраюзеры! Не так давно я начал искать работу на позицию junior разработчика. Даже благодаря моему скромному резюме мне удалось побывать на не малом количестве собеседований за сравнительно малый промежуток времени. Из каждого собеседовании я выносил для себя что-то новое, где-то были мои проколы, но гораздо интереснее было замечать фэйлы меня собеседующих. Собственно о таких проколах я и хотел бы рассказать.

Большого слона едят по кускам. Эта довольно известная метафора из книги Глеба Архангельского, говорит о том, что к любой глобальной цели ведет путь из n-нного количества мелких шагов. Нельзя сказать, что мысль эта оригинальна (в той или иной степени, она присутствует во многих книгах по управлению временем, тот же Кови и его «заточка пилы» или Getting Things Done Аллена и его полет на высоте 30 или 50 тысяч миль) однако от этого идея не становится менее правильной. Давайте еще раз: большого слона едят по кускам.

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

Итак, для начала о правильной постановке цели.

Вопрос продуктивности и ответственности всегда стоит на первом месте среди требований к новым сотрудникам.

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

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

Не претендуя на библию или «настольную статью программиста» я хочу поделиться полезными находками в моей любимой IDE, не скатываясь в тупую копипасту мануалов и скучных списков хоткеев, только то, что я сам использую постоянно и над чем удивляются коллеги: «о! а так можно?»

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

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

Эта статья о том, как можно избавиться от дублирования сквозного кода, и как сделать его чуточку лучше с помощью АОП.

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

В отечественном IT я часто наблюдаю следующую картину: тимлидом часто становился лучший (?) разработчик из команды (aka 23-летний сеньор). А чтобы стать руководителем проекта (project manager) иногда достаточно просто знать английский и «павэрпойнт» на уровне пользователя. Это реалии отечественного аутсорсинга и с этим нужно как-то жить.

В итоге часто получается как-то так:

Потому что на десять сеньоров по статистике девять тупят.

Вроде простой вопрос, даже не понятно что на него ответить, правда?
Мы все знаем как создать переменную, как получить значение переменной, как взять ссылку на переменную в конце концов.
Но как они работают изнутри?
Что происходит в интерпретаторе, когда вы изменяете значение переменной? Или когда удаляете ее?
Как реализованы типы переменных?

В этой статье я постараюсь раскрыть именно эти темы.

Abstract

Переменные в PHP выражены в виде неких контейнеров, которые хранят в себе тип переменной, значение, кол-во ссылающихся переменных на этот контейнер, и флаг — является ли эта переменная ссылочной.

На этот пост меня вдохновило исследование потребления памяти для моего текущего большого проекта на ZendFramework. Как обычно, по результатам исследования, я был шокирован нашей программистской самонадеянностью, которая нередко присутствует, когда мы пишем что-либо большое на PHP. Да и, наверное, не только на PHP.

Но обо всём по порядку.

Данная статья является логическим продолжением следующих статей:

• Работа с памятью (и всё же она есть)
• Насколько большие массивы (и значения) в PHP? (Подсказка: ОЧЕНЬ БОЛЬШИЕ)

U.S. English Basic Skills Test (40/m)
www.odesk.com/tests/511?tot=344&pos=0

English Spelling Test (U.S. Version) (40/m)
www.odesk.com/tests/688?tot=344&pos=1

English Vocabulary Test (U.S. Version)
www.odesk.com/tests/693?tot=344&pos=4

Привет, хабр! Продолжаю свой цикл материалов про маркетинг, продажи и клиентский сервис веб-студий и агентств. Сегодня хочу рассмотреть такую локальную тему, как заключение договора на создание сайта, и поговорить про его тонкие места.

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

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

Итак, я подготовил некий список неочевидных моментов, с которыми мне неоднократно приходилось сталкиваться на практике. Начнем:

Установка копирайта и публикация в портфолио

Очень часто при общении с заказчиком при запуске нового проекта конфликтным моментом становится размещение «марки» студии на сайте («Сделано в XXX » и пр.). Если данный момент никак не обозначен в договоре, то убедить заказчика прислушаться к вашим доводам бывает сложно. Часто проблемы возникают в самый последний момент, даже если изначально лейбл присутствовал и на макетах, и на тестовой зоне: «Ой, а мы не думали, что так и пойдет на основную версию сайта». Итак, что рекомендуется сделать:

Привет, Хабр! В данной статье речь пойдет про Standard PHP Library (SPL). На хабре до сих пор нет толкового мануала об этой библиотеке, которая уже стала частью ядра PHP (с версии 5.3). Данная библиотека содержит набор интерфейсов, классов структур данных, итераторов и функций, с помощью которых можно значительно упростить себе жизнь и повысить качество кода. В данной статье я рассматриваю такую часть библиотеки, как структуры данных. Также я покажу альтернативные решения поставленных задач и сравню скорость выполнения в обоих случаях.

Мне часто задают вопрос: «Как ты находишь время?». Чаще всего речь идет об open source, иногда о книгах, изредка — о других вещах. Обычно я уклонялся от ответа чем-нибудь вроде: «Блин, не знаю, просто беру и нахожу». Но этот ответ не слишком полезен. Да и мне было интересно, смогу ли я справляться со временем еще лучше. Так что я немного порефлексировал, и вот как я нахожу время:

Дорогой Хабр!

Почему пост в хабе фриланс? Потому что поездки и путешествия нередко являются частью быта фрилансера.

Так получилось, что с самолётами, а точнее с полётами на них, я дружу давно. Совершаю с десяток поездок в год на этом виде транспорта. В связи с этим, накопились некоторые наблюдения. Может быть примитивные, но успешно применяемые на практике. К тому же близится время зимнего отдыха, поэтому актуальность темы присутствует.

Предлагаем вашему вниманию очередную подборку с ссылками на новости и материалы.

Приятного чтения!

Вот и пошел отсчет последних дней года. Пора выбирать подарки тем людям, которые, так или иначе, принимали участие в Вашей жизни в течение этого года. И жизни не только личной, но и профессиональной. А что может быть приятнее для коллеги по цеху, чем маленький кусочек хорошего кода, обернутый в Pull Request?

24 Pull Request — это Open Source инициатива, приуроченная к (католическому) рождеству. Авторы призывают сказать Спасибо тем людям, труд которых, и возможно не раз, помогал Вам в решении разнообразных проблем, и предлагают делать для этого по коммиту в день, вплоть до самого (католического) рождества.

Когда мы заказываем костюм в ателье или дизайн интерьера, нас не просят прийти с готовыми мерками, выбранным фасоном или цветом потолка. Профессиональные модельеры и дизайнеры задают вопросы и предлагают решения на основе наших целей.

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

Чуть лучше дело обстоит в продуктовой разработке, особенно в стартапах, где генерация требований равномерно распределена по всему жизненному циклу работы над продуктом. Благодаря принципам Lean StartUp: построить -> измерить -> изучить, продуктовые команды работают более короткими циклами. На входе каждой итерации — новая порция требований для «эксперимента», в формулирование которых часто вовлечена вся команда.

В заказной разработке я наблюдаю 3 типа проблем, связанных с ожиданием готовых требований от клиента:

1. “Бизнес” не умеет формулировать хорошие требования, потому что не понимает процесса разработки и технологических возможностей. Спецификация содержит представление заказчика о решении проблемы, докопаться до сути которой по документу сложно.
   
   
2. “Бизнесу” не хватает времени на проработку требований. Часть вариантов использования системы, не продуманная заранее, вбрасывается в ходе разработки. Чем меньше практик, поддерживающих итеративный процесс (CI, автоматизированное тестирование, ограничение по количеству фич в работе), тем сложнее вносить изменения в требования.
   
   
3. “Бизнес” и “разработка” говорят на разных языках. Как следствие — ложное понимание требований, не проясненные предположения, вытекающие из них 'сюрпризы' в момент демонстрации. Несуществующую систему сложно описать на бумаге. Отсюда вытекают проблемы, которые можно обобщить словами заказчика: “Я не знаю точно чего хочу, но точно знаю чего не хочу”.

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

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

Ниже — обзор продуктовых техник, которые могут в этом помочь.

Совсем недавно проект «Рейтинг Рунета» опубликовал неудивительную и оттого ещё более печальную статистику об оформлении отношений между заказчиком и веб-студией.

Шокирующие факты:

• 17,5% процентов всех сайтов (и более 30% сайтов дешевле 100 000 рублей) делается вообще без всяких договоров.
• Более 26% сайтов дешевле 300 000 рублей делается с формальным договором, служащим лишь основанием для перечисления денег.
• Более 60% сайтов дешевле 100 000 рублей делается без техзадания или по техзаданию клиента.

Это говорит о том, что рынок крайне медленно учится на ошибках тех, кто уже добрался до «высшей ценовой категории», а также не понимает, что не умеет работать с рисками взаимодействия с клиентом. Поэтому мы решили поделиться уроками из истории нашей компании, чтобы помочь коллегам на рынке (и, возможно, заказчикам их услуг) сохранить некоторое количество денег, времени и нервов.

Это совсем краткий пост о причинах возникновения Deadlock

В более менее нагруженных проектах, использующих транзакции InnoDB, в любой момент может возникнуть ошибка вида

«Deadlock found when trying to get lock; try restarting transaction»

Главное не паниковать при виде этих страшных слов, сейчас мы разберемся почему это происходит.

4 года назад я открыл для себя понятие «фриланса» и описал впечатления в статье: habrahabr.ru/post/53938

Думаю, есть смысл поделиться последними наблюдениями.