Добрый день.
Для меня, моя жизнь как программиста, делится на два этапа. До того как я познакомился с WPF, и после. Мне пришлось очень плотно работать с этой технологией в рамках одного проекта, в результате чего я приобрёл некоторые знания, которыми хочу с вами поделиться. То что написано ниже, не откровения, и для тех кто знаком с WPF может показаться банальностью. Всё это описано в сети, в том или ином виде, проще или сложнее, но есть у всех этих описаний одна особенность — английский язык. Поэтому я приведу ниже очень короткий, но как мне кажется ёмкий пример того, что можно сделать при помощи Data Templates. Особенно этот пример будет интересен тем, кто только посматривает в сторону WPF.

Вступление

Я уже довольно давно читаю Хабр, и много раз видел посты про тайм-менеджмент и про то, как «улучшить свою жизнь за 5 минут». Так случилось, что около полутора лет назад я и сам заинтересовался тайм-менеджментом, и с тех пор постоянно испытываю разные методики в надежде скомпилировать нечто своё, полностью удовлетворяющее моим потребностям. Пару месяцев назад я в очередной раз пересмотрел свой подход к управлению временем, и, кажется, нашёл нечто, асимптотически стремящееся к идеалу :). Именно этой методикой я и хочу поделиться с уважаемыми хабраюзерами в надежде на то, что кто-нибудь сможет почерпнуть из неё что-то полезное.

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

Шаблоны

Шаблоны мы будем складывать в sites/all/themes/mytheme/templates. Создадим шаблоны page.tpl.php — для страниц, node.tpl.php — для контента, block.tpl.php — для блоков, comment-wrapper.tpl.php — для блока с комментариями, comment.tpl.php — для одного комментария, header.tpl.php — для шапки, footer.tpl.php — для подвала, region.tpl.php — для регионов. Также, по аналогии с препроцессами, мы можем создавать файлы типа node-story.tpl.php для отображения материала типа story или block-user.tpl.php для блока user. Это позволяет темизировать отдельно разные типы содержимого сайта.

Произошло это в начале 2008 года, когда я еще работал в одном крупном украинском банке инженером в IT-департаменте. Только спала новогодняя праздничная суета, и нагрузка на подразделения техподдержки немного поубавилась, как один из подотчетных мне web-серверов сообщил о заканчивающемся на диске месте. Беглый анализ показал, что стремительно росли логи IIS сервера, на котором крутится один из публичных платежных комплексов банка. Мои опасения оправдались – на сервер началась DDOS атака.

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

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

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

Что такое хорошо

Договор — это хорошо. Хороший договор — ещё лучше. Я искренне рад, что есть люди, согласные с этим. (Именно люди: ибо не один, не два, не три и даже (остросюжетный триллер) не четыре человека.)

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

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

Отсюда вывод № 1: сейчас нельзя назвать ни один из имеющихся (в том числе, здесь, на хабре) договоров хорошим. Но это ещё не всё.

Меня часто спрашивают, какой мой любимый компонент в Zend Framework, и я всегда отвечаю: «Forms» (формы).
В парадигме модель-представление-контроллер формы всегда играют непростую роль. Конечно, форма — это всего лишь HTML,
но для меня это нечто более абстрактное.
По сути, форма — это HTML, средствами которого пользователь вводит и получает данные, но кроме этого форма еще выполняет
нормализацию, проверку, фильтрацию данных и вывод сообщений об ошибках, если они есть.
Это может потребовать довольно-таки значительного объема кода.

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

Пару месяцев назад я проводил на работе анализ ИТ инфраструктуры, в ходе которого нужно было установить наиболее слабые места и дать рекомендации к улучшению. Уверен, ситуация с которой я столкнулся известна многим. За несколько лет, компания существенно изменилась и заметно подросла, однако некоторые элементы в используемой ИТ инфраструктуре так и остались неизменными за прошедшие 10 с небольшим лет. В результате, регулярно придумывались различные заплатки и изощрения дабы собрать все воедино, что, очевидно, не добавляло стабильности и эффективности общей системе. Итогом являлся пересмотр общей инфраструктуры и требований бизнес-процессов с целью выбрать новое единое решение. Другими словами – революция, не эволюция.

Совершенно случайно набрёл на одно интересное видео под названием Situating Personal Information Management (PIM) Practices within an Organization, почитал документ(создатели PIM подошли к этой проблеме основательно — исследования, тесты, теории, мне кажется, некоторые даже защитили кандидатские и докторские по этой тематике) и оказалось что те guidelines для организации хранения информации и быстрого доступа к ней, которые изложены в статьях, я уже давно и успешно использую в своей повседневной работе. И появились они у меня, как вы понимаете, не от хорошей жизни.
Так уж получилось, что работая ПМом, количество проектов у меня не опускалось ниже 5 и стабильно держалось в диапазоне 5 -10. Проекты были в основной своей массе небольшие, где то 3-5 месяцев длительностью и 2-4 разработчиков (ну и плюс сетевые администраторы, тестеры в проектной команде). Но когда к этому богатству добавился production support и maintenance и количество важных писем перевалило за 50-70 в день, пришлось задуматься насчет эффективного структурированного хранения проектной информации, её поиска, напоминаний о запланированных событиях. Далее описание что и как получилось...

Улучшение user experience и повышение юзабилити сервиса posterxxl.ru привело к росту чиcтой прибыли на 133%.


Для большого количества отечественных e-commerce сайтов и интернет-магазинов рост прибыли возможен без дополнительных затрат на рекламу и продвижение, за счёт улучшения пользовательских качеств сайта. О том, как это было сделано на примере сервиса posterxxl.ru вы узнаете из этой статьи.

Update (2014): Это статья 2007 года, которая, к моему удивлению, до сих пор пользуется спросом. По этой причине я обновил её в соответствии с новыми правилами оформления постов на Хабре, и добавил подсветку синтаксиса для примеров кода. Если кому-то захочется что-то добавить или исправить, исходник текста с хабра-разметкой выложен в открытый доступ: gist.github.com/dreikanter/2b4ee996d7a775e707d7

Аннотация от переводчика

PHP — один из самых широко распространенных языков разработки веб-приложений и при этом один из самых спорных. Я очень часто видел негативное отношение к этой технологии, да и недостатки, провоцирующие это отношение — не для кого не являются секретом. Тем не менее, PHP активно эволюционирует и во многих отношениях постепенно становитс лучше. Одним из серьезных шагов его развития, на мой взгляд, является появление MVC-фреймворков, призванных систематизировать процесс разработки веб-приложений и приучить к порядку разработчиков, которым зачастую здорово не хватает силы воли, чтобы при всей предоставляемой языком свободе, сохранить грамотную и красивую инфраструктуру разрабатываемого ПО (сразу уточню, что последнее утверждение субъективно и основано исключительно на виденном мной коде различных программных решений).

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

Я думаю многие со мной согласны, что Doctrine — один из самых мощных и удобных ORM для PHP, но с недавнего времени возможностей оного мне перестало хватать. Начнем с того что невозможно использовать ассоциации с условиями фильтрации, «волшебный» поиск с учетом перевода через I18n и много другого.

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

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

Наткнулся вчера на этот инструмент и не смог пройти мимо, провел ночь за написанием тестов, а теперь хочу поделиться находкой. QUnit — это библиотека от разработчиков jQuery, позволяющая писать unit-тесты для кода на javascript. Удобна в использовании, ничего лишнего, осваивается за 20 минут, выгода от применения — колоссальная.

Самым нетерпеливым сразу ссылки:
Официальная документация на сайте jquery: docs.jquery.com/QUnit
Реальные примеры тестов (для модулей jquery): view.jquery.com/trunk/jquery/test/unit
Руководство для начинающих (англ): www.swift-lizard.com/2009/11/24/test-driven-development-with-jquery-qunit
Система распределенного тестирования (гениально и просто): testswarm.com

Под катом информация о преимуществах юнит-тестирования применительно к js и разбор возможностей библиотеки на примерах.

Многие задают мне один и тот же вопрос:
«Как дебажить этот $%*!%$! JavaScript?».

Так вот, во-первых JavaScript — не $%*!%$! А как я его дебажу — сейчас расскажу.

(Примечание: наверное эта статья больше для новичков. Так что не судите строго)

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

В этом топике я постараюсь обобщить материал про сжатие данных. Сжиматься будет css, js, html.

В повседневной работе приходится сталкиваться с довольно однотипными ошибками при написании запросов.

В этой статье хотелось бы привести примеры того, как НЕ надо писать запросы.

Профилирование PHP-кода

Рано или поздно каждый из нас сталкивается с унаследованным кодом и его оптимизацией. Дебаггер и профилировшик в такой ситуации — лучшие помощники программиста. У тех кто работает с PHP, благодаря Дерику Ретансу (Derick Rethans) есть хороший инструмент — xDebug. Информации касательно xDebug много даже в рунете, поэтому речь в этой статье пойдет не о нем.

Наткнувшись на упоминание о профилировщике для PHP я сразу подумал об xDebug ( о проприетарных инструментах от Zend я давно уже успел позабыть ), но на этот раз ошибся — речь пойдет об XHProf.
XHProf

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

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