От переводчика: Часто сталкиваюсь с тем, что компании относятся к технической поддержке пользователей как к второстепенному процессу, а между тем качественная техническая поддержка, — это, выражаясь официальными терминами «основа устойчивого развития бизнеса и лояльности клиентов». В США и многих европейских странах поддержка пользователей возведена «культ», и когда сравниваешь то, как поддерживают клиентов «там» и «у нас», то становится печально (но ситуация постоянно улучшается). Действительно, для оказания отличной техподдержки знание предмета — это не самое главное и нужны дополнительные навыки общения. Но все исправимо и для того, чтобы вдохновиться и запустить собственную техподдержку на высоком уровне предлагаю перевод статьи «Customer service skills you need in 2013» посвященную рекомендациям по навыкам необходимым для оказания отличной технической поддержки.

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

Есть ряд принципов, которые нужно обязательно использовать при проектировании сайтов.

1. Оригинальные идеи. Именно идеи будут основой проектирования. Это самое важное, старт всего проекта. Очень важно не делать копии уже существующих проектов, почти всегда стоит задача сделать лучше, чем любой прямой или косвенный конкурент. Причем лучше на несколько порядков, иначе не получится переманить целевую аудиторию с тех сайтов, где она уже обитает. Идеи должен генерировать как проектировщик, так и инициатор проекта, тот самый носитель главной идеи.
   
   
2. Переносим оффлаин опыт. Один из важнейших принципов успешного проектирования – переносить опыт из оффлайна в онлайн. Нужно представить себя на месте представителя целевой аудитории, подумать, как он удовлетворяет свои потребности, связанные с тематикой проекта в оффлайне, и сделать то же самое, только лучше, в онлайне. Для иллюстрации принципа представим, что мы проектируем социальную сеть автолюбителей, где типичный представитель целевой аудитории имеет автомобиль, покупает автозапчасти в магазине возле дома, общается с приятелем Васей из соседнего гаража. Понимая поведение нашего потенциального пользователя в оффлайне, мы сразу можем предложить ему: привязать автомобиль к профилю по VIN-номеру с подробным справочником о нем; сделать некий аналог авторынка с разными продавцами, возможностью сравнивать цены, отзывами о работе; сообщество владельцев таких же автомобилей, с каждым из которых можно будет пообщаться и т.д. Это маленькие идеи, которые мне пришли в голову буквально на ходу, просто я представил себя на месте потенциального пользователя. Всего за пару минут можно сформировать несколько десятков неплохих, а самое главное полезных идей.
   
   

В этой статье я попытаюсь поделиться своим опытом в проектировании пользовательской бизнес-логики. Это явно не претендует на полноценный ликбез, т.к. я всего лишь вспоминаю то, через что прошёл лично я, какие ошибки я допустил, и как мне их удалось (или не удалось) исправить в будущем. Наверняка, опытные системные архитекторы уже все проходили и знают, однако надеюсь, что некоторые советы таки будут полезны.
Мы использовали (и используем) клиентскую часть на WPF/Silverlight, WCF сервисы и СУБД Oracle, Postrges, MsSQL. Код написан по MVVM, использована Prism для модульности и навигации. Не могу точно сказать, какие из тезисов подойдут для других платформ и языков.

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

Итак, поехали.

Today's software engineering word is «farpotshket.» This is a Yiddish word meaning, «broken, because someone tried to fix it.»
(с) Andr Zerozero

Схлеснулись мы тут на днях на работе по вопросу «А хорошо бы закешировать регулярку», в совершенно банальной функции

  uncached = function(data_in) {
    return /_(\d)+(?:#(\d)+)?$/.exec(data_in);
  };

сделав как-то так

  cached = (function() {
    var pattern = /_(\d)+(?:#(\d)+)?$/;
    return function(data_in) {
      return pattern.exec(data_in);
    };
  })();

Идея популярная, но многие ли задумывались о реальном профите и накладных расходах?

В прошлой статье, я привёл свою классификацию механизмов аутентификации. Теперь я поделюсь методами их оценки и сравнения.
Всего можно выделить 4 основных показателя системы аутентификации:
1. Затраты на установку и обслуживание.
2. Эффективность.
3. Надёжность.
4. Безопасность.

Я – ваш новый технический директор.

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

Профессионалы ли мы?

Это главный вопрос. Я расскажу, чего я от вас жду, и это определит ответ на вопрос, профессионалы ли мы.

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

В последних двух выпусках Радио-T ведущие пытались обсудить GIT. Евгений (@Umputun) задавался вопросом зачем нужен rebase и очень удивился, когда я спросил, редактирует ли он коммиты. На мой взгляд, чтоб понять GIT, достаточно вникнуть в процесс разработки Linux Kernel, т к создавался он именно для этого.

Для начала скажу что я очень большой любитель что-то попатчить и потвикать, даже если для этого нету особой необходимости. И вот недавно рассматривая статистику XCache на своем сервере я подумал что смог бы оптимизировать объем памяти который он тратит на опкеш (opcache) файлов различных фреймворков. Сделать это просто — переписать все используя только один, файлы которого были бы общими для всех сайтов, каких у меня порядка 20-ти, но в большинстве они довольно простенькие и особого труда их переписать мне бы не предоставило. И тут я начал поиск того самого фреймворка, который в идеале имел бы достаточно фич чтобы разработка была простой, и в тоже время был легким и быстрым. Вот те которые мне понравились и мои мысли о них.

Текстовый редактор bootstrap-wysiwyg — это всего 1.5 Кб в минифицированном и сжатом виде и чуть больше 6 Кб исходного кода, базовые функции редактирования на основе execCommand, drag-and-drop для вставки изображений, поддержка стандартных горячих клавиш и ничего лишнего. Редактор работает в современных браузерах (Chrome 26, Firefox 19, Safari 6) и на мобильных платформах (IOS 6 iPad/iPhone, Android 4.1.1 Chrome). Зависимости — jQuery, jQuery HotKeys и Bootstrap.

По мере работы с базами данных, ознакомления с их плюсами и минусами, возникает момент, когда принимается решение миграции с одной СУБД в другую. В данном случае возникла задача переноса сервисов с MySQL на PostgreSQL. Вот небольшой перечень вкусностей, которые ждут от перехода на PostgreSQL, версии 9.2 (с более подробным списком возможностей можно ознакомится тут):

• наследование таблиц (есть ограничения, которые обещают в будущем исправить)
• диапазоны: int4range, numrange, daterange
• поддержка из коробки несколько языков для хранимых функций (PL/pgSQL, PL/Tcl, PL/Perl, PL/Python и голый C)
• оператор WITH, позволяющий делать рекурсивные запросы
• (планируется) материализованные представления (частично они доступны и сейчас — как IUD правила к представлению)
• (планируется) триггера на DDL операции

Как правило, существующие решения опираются на работу с уже готовым SQL дампом, который конвертируется в соответствии с синтаксисом целевой БД. Но в некоторых случаях (активно использующееся веб-приложение с большим объемом информации) такой вариант несет определенные временные затраты на создание SQL дампа из СУБД, его конвертации и загрузку получившегося дампа снова в СУБД. Поэтому оптимальней будет online-вариант (прямиком из СУБД в СУБД) конвертера, что может существенно уменьшить простой сервисов.

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

Вот уже полтора года я использую Symfony 2 для разработки web-приложений. За это время я трижды начинал новый проект, еще в трех проектах работал с унаследованным кодом, а также провел ревью около 15 тестовых заданий на знание фреймворка.

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

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

За время своей работы верстальщиком, мне довелось иметь дело с кучей разных макетов как от новичков дизайна (или порой просто левых людей), так и до профессионалов. И за это время я успел набрать приличную выборку наиболее типичных багов в макетах, которых не в состоянии избежать даже маститые специалисты. Сразу оговорюсь — в некоторых организациях есть внутренние «требования к дизайн-макетам», и по идее, при несоответствии дизайна этим требованиям, он должен без вопросов отправляться на доработку, но реалии таковы, что зачастую проще самому внести нужные правки, чем гонять документ туда-сюда по трекеру. Но даже в этих «требованиях» упомянуты далеко не все очевидно возможные «косяки». Постараюсь привести наиболее популярные и универсальные (без личностной привязки). Да, кстати, все баги привожу под использование фотошопных psd — ну уж де-факто это стандарт в веб-макетах. Да и не попадались мне ещё макеты в векторе (и надо сказать, слава богу).

Что я успел понять про MySQL за несколько лет его разработки:

• развивать не ломая обратной совместимости его нельзя
• MySQL со сломанной обратной совместимостью никому не нужен.

Я опишу две серьёзные проблемы ДНК MySQL, с которыми косвенно сталкивается любой пользователь MySQL 5.1 и 5.5 (насчёт 5.6 не проверял, но не думаю, что этот момент поменялся).

Как вообще MySQL работает?

В общем-то на Хабре достаточно постов о фрилансе вообще, и о Elance.com в частности — пост ниже является попыткой поделиться опытом.
Информации много не бывает — посему позвольте начать.

Если вы впервые слышите про Elance — настоятельно рекомендую прочитать два поста ниже, serjio очень хорошие советы даёт по поводу регистрации, наполнения портфолио, бидов и прочего, что необходимо знать:

• Как начать работать на Elance.com. Краткое руководство для веб-дизайнера.
• Работа на elance для новичков. Часть2

В данной статье будет показано как можно реорганизовывать код написанный в «простом» JQuery стиле в код на Backbone, с использованием представлений, моделей, коллекций и событий. Реорганизация будет постепенной, так чтобы этот процесс дал четкое понимание основных абстракций в Backbone. Статья рассчитана на тех кто использует JQuery и хотел бы познакомится со схемой MVC для клиентского кода.

Неприятности случаются… Неожиданно плохой фидбек, проблемы с заказчиком или коллегами, не повысили зарплату, странные баги, внезапный овертайм или закрытие проекта — подобные события запускают цепочку реактивных реакций:

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

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

• Как узнать каждое состояние и предугадать следующее?
• Как помочь выйти себе и собеседнику из цепочки?
• Что не делать, чтобы не усугубить ситуацию?

Все системные администраторы рано или поздно сталкиваются с проблемой мониторинга рабочих серверов. Для решения этой проблемы существует целый зоопарк разнообразных путей. Весьма популярной системой является Nagios из-за своего мощного механизма оповещений. Так же, часто используются системы больше сконцентрированные на сборе значений различных параметров, и отслеживании этих изменений с течением времени для сбора статистики, такие как: Cacti, Zabbix, Ganglia . Причем Ganglia незаслуженно обделена вниманием Хабрасообщества. В этом топике я постараюсь исправить этот недостаток, и показать насколько это гибкий и полезный инструмент.