Дорогие друзья! На прошлой неделе вышел стабильный релиз чудесной key-value базы Redis версии 2.0 с внушающим количеством нововведений. Эта новость особенно нас обрадовала, так как мы уже год используем Redis в наших нагруженных проектах и впечатления только положительные. Мы обновили PHP клиент Rediska, добавив поддержку новых возможностей.

Вот и мне посчастливилось познакомиться с git. Каюсь, пользуясь Subversion, я знал, как в IDEA или TortoiseSVN сделать то, что мне надо, но даже не представлял, что происходит за сценой. В данном случае я решил подойти к git более ответственно и хорошенько изучить его перед использованием. Сейчас я знаю какие команды надо использовать для выполнения задуманного, но не знаю, как это сделать в IDEA или TortoiseSVN.
Но я решил пойти еще дальше и узнать, что происходит в самой директории .git. Там оказалось все настолько интересно и просто, что я решил поделиться этим с вами.

Уже около полугода для разработки веб-проектов используем Symfony 2. Накопился список полезных библиотек и бандлов, не входящих в состав symfony-standard, но значительно экономящих время и избавляющих от изобретения велосипеда.



Обзор больше теоретический и включает следующие разделы:

• Админгенераторы
• Пользователи
• Импорт/экспорт xls
• API и OAuth 2.0
• Меню/навигация
• Мультимедиа
• Формы
• Поиск
• Пагинация
• Файловая система
• HTTP клиент

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

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

Веб-разработчику консоль нужна, но не на столько что бы бросив все дела начинать читать толстенные книжки по линуксу. Именно поэтому я учился консольным хитростям от случая к случаю и, судя по моим сотрудникам, многие поступают точно так же. Раскрою пару удобных секретов, без которых я уже не могу жить.

Чуть более двух лет назад я опубликовал статью Другое видение скучных GTD планировщиков через призму RPG игр, в которой описал свою старую идею про совмещение работы над software проектами и элементов RPG игр.

Все вы знаете, что такое GTD. Проекты, таски, майлстоуны и дедлайны. Множество контор и команд разработчиков используют ту или иную систему на базе (или не на базе) GTD для контроля задач в проектах в своей повседневной работе. Я предлагаю заменить основные понятия этой методологии на термины многопользовательских RPG, добавить плюшек, статистику, достижения, красивости и фан. Получим тот же планировщик, но не такой скучный и с дополнительной мотивацией.

Топик тогда собрал 100500 комментов (в основном «супер! хочу!»), а особо заразительные собрались в команды и стали воплощать идею в жизнь. Так что же было сделано за эти два года?

Предисловие

Я капризный. Я жалуюсь о многих вещах. Многое в мире технологий мне не нравится и это предсказуемо: программирование — шумная молодая дисциплина, и никто из нас не имеет ни малейшего представления, что он делает. Учитывая закон Старджона, у нас достаточно вещей для постижения на всю жизнь.

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

PHP — единственное исключение. Фактически каждая деталь PHP в какой-то мере поломана. Язык, структура, экосистема: всё плохо. И даже нельзя указать на одну убийственную вещь, настолько дефект систематичный. Каждый раз, когда я пытаюсь систематизировать недостатки PHP, я теряюсь в поиске в глубину обнаруживая всё больше и больше ужасных мелочей(отсюда фрактал).

PHP — препятствие, отрава моего ремесла. Я схожу с ума от того, насколько он сломан и насколько воспеваем каждым уполномоченным любителем нежелающим научиться чему-либо ещё. У него ничтожно мало оправдывающих положительных качеств и я бы хотел забыть, что он вообще существует.

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

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

В статье Reddwarf для создания Java-сервера на примере онлайн-игры «Камень-ножницы-бумага»: Сервер было описано, как сделать сервер. Но поиграть на таком сервере без клиента невозможно. Поэтому в этой статье попробуем написать простейший клиент и поэкспериментировать с сервером.

В статье RedDwarf — cерверная платформа для разработки онлайн-игр на Java я рассказал об особенностях этой платформы для создания игровых серверов. В данной статье я попробую показать на примере, как написать сервер и использованием RedDwarf.
В качестве примера решено было написать онлайн-реализацию игры «Камень-Ножницы-Бумага».
В этой статье мы напишем сервер и попробуем его запустить. В следующей статье напишем для этого сервера небольшой клиент и проверим их работоспособность.

Создавая новый проект на Django, ты в очередной раз лезешь изменять конфигурации своего web-сервера. И вроде бы ничего страшного, да только конфигурации ты меняешь уже чаще, чем выгуливаешь свою собаку. Как-то не правильно? Согласен (собака, думаю, тоже не возражает). Выход – виртуальный хостинг. Изучив пару статей в Интернете, ты забиваешь конфигурации своих сайтов в httpd-vhosts.conf. И какое-то время даже радуешься этому. Проходит время и на локальном хосте у тебя уже не два с половиной сайта, а десятки проектов (пусть даже небольших). И, открывая в очередной раз httpd-vhosts.conf, чтобы добавить какую-нибудь опцию, ты начинаешь думать «А был ли мальчик?», действительно ли ты создавал этот сайт? Ведь в такой окрошке из проектов уже нелегко что-либо отыскать. А если еще учесть, что половина проектов взаимодействует с web-сервером при помощи модуля mod_python, а другая – при помощи модуля mod_wsgi, например, тогда вообще становится грустно работать. Да и жить тоже становится грустно (а уж как ваша собака то у дверей грустит).

Тут я попробую рассказать, как сделать виртуальный хостинг более дружелюбным, а заодно и как настроить вышеупомянутые модули (mod_python и mod_wsgi).

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

Бесплатная CMS это всегда компромисс, компромисс между целым рядом очевидных факторов, перечислять которые в рамках данного ресурса смысла пожалуй нет, т.к. они всем давно известны. Безусловно, среди всего разнообразия бесплатных СМS можно выделить некоторые, которые будут лучше или хуже в каких-то отдельных номинациях, вроде скорости работы, простоты освоения новичком и т.п. Но в данной статье речь не об этом. Я просто хочу поделиться опытом успешного решения проблемы скорости генерации страниц в Joomla с помощью кеширования. Причём кеширования очень радикального, на «уровне» index.php.

Хочу сразу отметить, что сие повествование не является каким-то принципиальным новшеством, и я не претендую на какие-либо лавры. Надеюсь, моё решение поможет хотя бы кому-то продлить «малой кровью» жизнь старого проекта на Joomla.

Я руковожу собственной компанией, занимающейся коммерческой веб разработкой, уже более 8 лет. За эти годы мы значительно выросли и количественно и качественно. У нас достаточно клиентов и работы всегда хватает. Но с каждым днем я все больше убеждаюсь, что если рассматривать веб-разработку с точки зрения бизнеса, то «игра не стоит свеч».

Доброго времени суток!

Предисловие

Когда-то я хотел познакомиться с Rails поближе, но не знал с чего начать, пока мне на глаза не попалась эта статья. Далее вы увидите перевод, смешанный с собственным опытом и свойственными мне лексическими и фразеологическими оборотами. Итак, поехали.

Введение

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

Однако, изучение Ruby on Rails является достаточно простым занятием. Это невероятно мощный фреймворк, который имеет огромное сообщество, продвигающее его вперёд. Итак, у нас возникает вопрос: какой способ изучить Rails является лучшим? Вот он — план занятий.

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

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

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

Но статья, на самом деле, не об этом. Я хочу рассказать про две замечательные команды git, которые я недавно для себя открыл. Это git blame и git bisect

Часть 1
Часть 2

Хотел я было закончить финансовым вопросом. Ан нет. пройдусь ка я по адским клоакам, именуемым в простонародье дизайном. Да простят меня представители сей славной профессии, но найти адекватного и качественного дизайнера на порядки сложнее, чем программиста. О особенностях — под катом

Вчера Karl Seguin – автор книги The Little MongoDB Book, которую часто рекомендуют для быстрого старта с MongoDB, опубликовал аналогичное руководство для Redis под названием The Little Redis Book (при участии Perry Neal). Книга состоит из 29 страниц, написанных за 2 коротких дня с использованием Markdown. Исходная разметка книги находится на GitHub. Сама книга распространяется свободно под лицензией Attribution-NonCommercial 3.0 Unported license.

Содержание книги

• About This Book
• Introduction
• Chapter 1 — The Basics
• Chapter 2 — The Data Structures
• Chapter 3 — Leveraging Data Structures
• Chapter 4 — Beyond The Data Structures
• Chapter 5 — Administration
• Conclusion

Скачать

The Little Redis Book (PDF)

Есть у меня серверок (да, да, именно серверок, сервером его назвать сложно). Железо старенькое (2 гига оперативы, AMD Athlon(tm) 64 Processor 3500+, програмный RAID). Админю я его сам, без особых навыков и познаний. Когда-то давным давно (больше года назад) поставил на него Debian 5.0 Lenny (это была вторая в жизни установка linux-системы, до этого ставил только Ubuntu на рабочий ноутбук) и панель управления ISPConfig3 по мануалу. Держу на нем несколько (штук 40) сайтов друзей и клиентов, Redmine, SVN и еще немного по мелочам.
Периодически все это безобразие падает (load average > 20), и приходится на сервере раз в пару часов перегружать apache или высасывать из пальца очередную попытку оптимизации. В общем полный раздрай и разруха. И вот в одну прекрасную субботу я подумал — а почему бы не решить вопрос раз и… И вот в общем.
Под катом — история убитых выходных + предыстория. Интересна в первую очередь мне, чтобы потом легко вспомнить что именно и зачем я ставил. Может быть интересна новичкам в интересном и нелегком (ох, ...) деле серверной оптимизации постепенным(!) переводом сайтов из-под Apache c его ModRewrite под Nginx (кстати, правильно это слово читается «энжинкс»меня поправили, Сысоев на конференциях не раз говорил, что название сервера стоит читать, как «энжин-икс», спасибо bayandin и DorBer ). Возможно, будет интересна более-менее опытным товарищам, оказавшимся в тех же условиях (Debian Lenny, ISPConfig3, слабое железо, несколько хороших, не сильно хороших и разных сайтов). И более опытным может быть интересно зайти, оставить пару комментариев.

Данная мини-заметка в первую очередь является ответом на вопрос. Так как мой аккаунт read-only, то вот такой вот способ ответа. «А жизнь-то налаживается!» ©

Первый вывод после прочтения вопроса и ответов — не делайте так, как предложил defuz. Он не понимает суть проблемы, и если вы сделаете как им предложено — скорее всего, вы потеряете данные.
Второй: alekciy тоже не совсем прав, но тут шансов на потерю данных гораздо меньше. Почти никаких.
Ну и третий: блин, ну когда же люди поймут, что владеть используемым инструментом это реально необходимо? Читайте документацию!

Привет, Хабр!
Мне по работе часто приходится импортировать Excel-документы средствами PHP.
Для этого я использую библиотеку PHPExcel, которая на сегодняшний день является весьма удобным инструментом.
Но есть несколько «скользких» моментов, связанных с чтением данных из ячеек, о которых я хочу рассказать хабрачитателям, а также разобрать функцию, решающую эти проблемы.

Оглавление

• Часть 1
• Часть 2
• Часть 3
• Часть 4
• Часть 5

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

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

Зачем вам нужен собственный фреймворк? (Why would you like to create your own framework?)

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

1. Что бы изучить низкоуровневую архитектуру современных веб-ориентированных фреймворков, в частности Symfony2 и ее компонентов.
2. Что бы создать фремворк «под ключ» для ваших специфических нужд. (Только прежде убедитесь, что ваши нужды действительно специфические)
3. Для эксперимента ради удовольствия ( научился и забил )
4. Для рефакторинга уже существующих приложений, которые нуждаются в более современных и устоявшихся практических решениях.
5. Что бы доказать что вы это можете (… пусть и с небольшой помощью)