Чем больше времени в день человек играет в онлайн-игру, тем лучше онлайн-игре - сильнее привязанность, быстрее тратятся (или весомее выглядят) купленные бонусы, больше шансов поймать на настроении, в котором клиент способен отправить смску. С другой стороны, начиная с некоторого легко достижимого уровня, чем больше игрок играет, тем ему хуже: красные глаза, проблемы на работе, нехватка времени на остальную жизнь. Основное оружие, которое есть в этом конфликте интересов у игр, - давать преимущество тем, кто проводит в онлайне больше времени (больше играешь - быстрее качаешься и т. п.). Побочный эффект такого подхода - ещё одно психологическое оправдание платных бонусов, "плата за неигру" (этот сидит в онлайне 24 часа, а я человек серьезный, времени у меня мало, я могу сидеть только 20 часов, заплачу за волшебный меч, чтобы с ним сравняться). Понятно, что именно игровая составляющая от этого страдает, вместо шахмат играть приходится в шахматы после 5 литров безалкогольного пива и с дорогим платным туалетом. Можно платить, можно мучаться, можно сдаться и убежать, умение играть хоть и играет некоторую роль, но явно второстепенную. Изменить это несложно, правильно поставленный вопрос как обычно уже содержит в себе ответ. Ограничение на количество времени, проводимого в игре, в день - и собственно всё, проблема решена. В момент регистрации человек осознанно подбирает более-менее комфортный для него режим, а дальше никакой азарт не позволит ему посидеть "ещё часок". Естественно ни одна игра не сделает этот шаг по собственной воле, естественно лет через двадцать в этом направлении начнет работать государство (как только курильщиков добьет, следующим будут именно Интернет-развлечения, а не алкоголь(*)). Менее очевидно (хотя, увы, и довольно маловероятно), что процесс может стартовать и какой-нибудь крупный общий конкурент всего игрового бизнеса - типа всеблагого Гугла. Запустив несколько полуклонов самых популярных игр в разных жанрах, но с этой фичей, и смирившись с меньшей доходностью, он может сделать более дружественный игрокам продукт(**), начать захватывать долю рынка и вынудить перейти на новый стандарт и остальных. Выигрыш же будет в основном бизнесе - уменьшится количество путей превращения трафика в деньги, тот кто сидит на других путях, будет потирать руки. (*) - А вы вспомните-почитайте об отношении к курению лет 40 назад и сравните его с нынешним. (**) - Исхожу из предположения, что выбирает игру пользователь сознательно и понимая, что красных глаз он _не_ хочет, а скатывается в них уже в аффекте от азарта. Предположение делается по своему кругу знакомых, на 100% в нем не уверен.

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

Как рассылают знатным блоггерам свои новости обычные бесплатные СУБД? Никак. PostgreSQL, безусловно, лучше. Он рассылает их в zip'е, а в zip'е html, а у html битая кодировка. Но зато UTF.

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

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

Т. е. просто скопировать файлы по-прежнему нельзя?

* Права доступа на столбцы, предоставляющие более тонкий контроль над важными данными.
* Раздельные локали для баз данных, что упрощает работу с PostgreSQL в многоязычных окружениях.
* Обновления «на месте» с помощью бета-версии инструмента pg_migrator, который позволяет перейти с версии 8.3 на 8.4 без существенного простоя системы.

Особенно радует сочетание бета-версии отдельного инструмента и отсутствие существенного(?) простоя. Просто перепустить демон по-прежнему нельзя?

* Новые инструменты мониторинга запросов, помогающие администраторам получить лучшее представление об активности запросов.

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

В любом случае, хочется пожелать успехов в погоне за обычной бесплатной СУБД. В плане методов продвижения - PostgreSQL уже побеждает

http://dnovikoff.livejournal.com/459190.html?style=mine#cutid1

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

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

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

Велосипед?

Как известно (сформулировано, к сожалению, не мной), любая трудовая деятельность делится на два типа активности: работу работать и управление управлять. По аналогии, но по другому критерию я бы разделил ещё и так: можно работу работать, а можно думу думать (и, разумеется, безделье бездельничать, но это сейчас к делу не относится).

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

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

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

Завхоз может обругать хирурга за небрежное отношение к инструментам ("взял чистый, а вернул грязный") и в качестве воспитательной меры сегодня скальпель ему не выдавать. Или выдать, но старый и тупой, который не жалко. Главврач может поехать спасать детей в захваченной террористами больнице или прорываться в комитет Государственной Думы с проектом закона о борьбе с коррупцией в медицине. Все они сегодня решили думать думу.

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

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

99% SMTP трафика это спам и вирусы.
90% оставшегося - автоматические уведомления различных роботов.

Почта - самый медленный из всех способов общения в Интернете (фактически, единственный, немгновенный).
Почта - единственный способ общения, который практически не развивается. Яндекс сделал цепочки и настраиваемые цвета! Р-р-р-революция в интерфейсе! Вконтакте или QIP таких революций по две в год делает. Открытие в бете IMAP'а (какого там года RFC?) - вообще комментировать стыдно. Сейчас ещё mail.ru его второй раз объявит.
Почта наименее ответственный способ общения. Даже левых асек (несмотря на техническую легкость) используется в 100 раз меньше, чем левых почтовых ящиков. А уж про левые анкеты в соцсетях и говорить смешно.

О том, что почта сольется с IM (социальных сетей тогда не было) умные люди говорили ещё лет 5 назад.
О том, что почта IM'у постепенно проигрывает, другие умные люди говорили ещё раньше.
О том, что всё живое общение перейдет в соцсети, я слышал года полтора назад.

Тем не менее, основной адрес, который пишут на визитках - адрес протокола smtp.
Самый посещаемый сайт Рунета - mail.ru, а не im.ru, и не social.ru.
И регистрацию в любом суперстартапе считают подтвержденной, если человек клацнул по ссылке, отправленную именно письмом.

Видятся 5 преимуществ, позволяющих жить этому облезлому монстру:
- в существующих интерфейсах удобнее отправлять файлы;
- в существующих интерфейсах удобнее настроить фильтры для указания, где что хранить, куда что скопировать;
- почта стандартизованнее, какой-то IM есть условно "у всех", а вот конкретный jabber или аська - уже далеко не у всех;
- анонимность иногда и плюс;
- инерция мышления ("как это?? отправить по одноклассникам то, что всю жизнь отправляли по почте??").

Кто сумеет перебить первые 4 преимущества, тот будет королем Интернета. Кто первым пойдет на прорыв пятого - тот будет героем.

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

Практика показывает, что задача не очень сложная. Большинство испытуемых так или иначе, но строит какие-то пропорции и в итоге получает некое число N. Даже если есть ошибка на порядок-полтора, это в общем не страшно - логически мыслить умеет, а то, что не знает, сколько в баке бензина - ну так и черт с ним, не заправщика нанимаем.

Термоядернее оказывается следующий вопрос, который я, кажется, изобрел сам. "Вот Вы заместитель мэра этого города. И на третий рабочий день к Вам подходит подчиненный, с докладной запиской о том, что 10*N бензоколонок не справляются и надо строить ещё N. Ваша реакция?". Ответы очень красивы, и мне кажется показательны в плане решения брать/не брать.

Известно и бесспорно, что работа равно произведению мощности на затраченное время. В случае живого сотрудника под мощностью можно смело понимать квалификацию (естественно квалификацию именно в том деле, которым человек занимается, а не "вообще", т. е., когда Платонов гонял мальчишек во дворах, имели значение его навыки дворника, а не писателя), а под временем то время, которое тратится на поставленную задачу (т. е. 8 часов минус перекуры и чтение ЖЖ, минус решение тех задач, которые человек ставит сам себе и которые не нужны руководству).

Продолжая рассуждение, формулу можно переписать так: Работа = Квалификация * (Трудолюбие - Нелояльность). Обращу внимание, что запись второго множителя достаточно принципиальна, вариант (Трудолюбие + Лояльность) был бы неверен. Ведь если сотрудник выделил N часов в неделю на то, что он называет работой (за это отвечает трудолюбие), то дальше его (не)лояльность лишь дробит это время на полезное и бессмысленное, КПД не может оказаться выше 100%, а значит и вклад этого фактора всегда отрицательный.

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

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

Более менее очевидно, что если сотрудник компании знает, что его коллега примерно равного статуса-способностей-положения-востребованности имеет существенно большую зарплату/иные бонусы, то он демотивирован ("меня здесь не уважают").

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

Выводы из всего этого достаточно туманны.

3 главных достоинства для IT-шника в вебе:
- ответственность;
- ориентированность на результат;
- инициативность.

3 главных недостатка:
- перфекционизм;
- лень;
- небрежность.

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

Предположение 2.
Производители умеют управлять качеством своих продуктов с точностью M% (M
В условиях этой модели у любого производителя есть две зоны выгодного качества:
первая - максимальное качество конкурентов +N+M.
вторая - максимальное качество конкурентов -N+M.

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

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

Если все конкуренты на рынке работают во второй зоне, то наступает сингулярность. Каждая следующая версия уменьшает максимум качества на (N-M)%, соответственно сокращает издержки и сроки создания продукта, качество стремится к нулю, скорость его относительного уменьшения увеличивается. Сингулярность. Это web 2.0.

Если все конкуренты на рынке работают в первой зоне, то наступает стагнация - качество постепенно растет, скорость выхода продуктов сокращается. Характерный пример - прохладительные напитки, новой версии Coca-Cola мы, наверное, вообще никогда не увидим.

Если конкуренты работают в обеих зонах, то скорее всего рынок разделится (Vertu vs обычные мобильники), в одной наступит сингулярность, в другой стагнация.

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

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

Будущему ученому нужно рассказывать не то, что было известно лет 50 назад в его области знаний, а то, как были получены эти сведения. Не то, какой фараон лежит в самой большой Египетской пирамиде, а то, почему считается, что там кто-то лежит, и какие есть основания думать, что папа в детстве звал это кого-то Хеопсом.

Нынешние курсы биологии и пр. напоминают изучение математики через заучивание теорем без их доказательства. Кстати, именно математику преподают правильно и именно в математике у СССР были лучшие результаты.

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

Это модель НЕ подобна модели Менделя, т. к. по ней каждый человек носит в себе один "ген", а не пару. Исходя из неё, носители животноненавистничества должны достаточно быстро (экспоненциально с отрицательным показателем) вымирать.

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

Многие спрашивают, играю ли я в теннис

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

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

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

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

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

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

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

А вот второй ответственности не должно быть слишком много - иначе это просто паралич.

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

"Из этого можно сделать два тома, как этот" (c).

Как кто-то, может быть, помнит, Вася делает заборы. Заборы Васи стоят долго, выглядят красиво и остаются в наследство правнукам хозяев. Берет он за свою работу 800 рублей в день, а забор длиной 50 метров делает за месяц. Раньше я об этом не писал, но если забор всё-таки нужно починить - он его чинит, расценки и скорость зависят от дополнительных условий, но времени и денег заделывание пробоины отнимает не больше, чем на строительство нового участка длиной с пробоину.

Коля тоже делает заборы. Но он их делает качественно, если уж он берется за свою работу, то может гордиться результатом. Конечно, за качество приходится платить: и стоит его работа подороже (1200 в день), и делает он не тяп-ляп, а 50 метров за два месяца, и ломается его забор за 2-3 сезона, и уж если ломается где-то, то переделывать нужно целиком, да и выглядит он обычно не очень. Но зато качество, не халтура какая-то.

А по халтуре, кстати, тоже есть специалист - Вова. 500 рублей в день и 50 метров за две недели, но и ломается такой, с позволения сказать, забор с первыми осенними дождями. Чинить его по кускам никто и не пробовал, падает он обычно сразу весь.

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

С другой стороны, все преступления делятся на умышленные (подсыпал мышьяка в чай) и непредумышленные (перепутал мышьяк с лекарством и случайно отравил). Казалось бы, с точки зрения "месть не самоцель", за вторые наказывать не надо - в самом деле, вероятность того, что один и тот же человек два раза случайно перепутает таблетки - ничтожна, да и тщательнее проверять их, опасаясь именно уголовного преследования, никто не будет.

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

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

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

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

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

Задачи, решаемые IT-шниками, бывают необходимые, полезные и вредные. Рассмотрим пример.

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

Обеспечение миграции пользователей версии N-3 и N-4 - полезная задача. Пользователи соответствующих версий будут нам признательны, и хотя их немного - почему бы и нет. С другой стороны, если ресурсов мало, задачей можно и пренебречь, их же мало.

Обеспечение миграции пользователей, на компьютерах которых одновременно установлены версии N-4 в расширенном режиме и пререлиз версии N-2 в обычном режиме, а версию N они хотят установить поверх N-4, но перейдя в обычный режим - задача вредная. Количество таких пользователей измеряется уже совсем смешными числами (возможно, все они сидят в нашем офисе), при этом пожелания свидетельствуют о том, что они всё очень хорошо знают и понимают, и либо справятся с миграцией, даже если она будет затруднена, либо смогут обойтись, если она будет вообще невозможна. Ресурсов же она естественно требует существенно больше, чем задачи нормальные.

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

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

1. Три года назад базовым способом поиска работы для программиста/сисадмина мне однозначно казалась связка job.ru/rabota.ru, соответственно искал я их там. Теперь мониторю только hh.ru. Это мой личный глюк или действительно что-то изменилось?

2. Теоретически и практически соотношение соискателей к нанимателям на рабочих сайтах 90/10. Теоретически в рекламной модели монетизации соотношение должно быть аналогичным. С другой стороны, платных пользователей среди нанимателей должно быть больше и в относительных (точно), и, возможно, даже в абсолютных числах. А на некоторых сайтах даже нет платных услуг для соискателей. С третьей стороны, соискатели обычно не лояльные пользователи сайта - поищут работу день-неделю-месяц-два и найдут её в конце концов, а вот наниматели сидят на них годами. Ну и наконец, количество соискателей определяется количеством нанимателей, на сайте без вакансий и просмотров резюме делать им нечего.

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

А давайте соберем IT-шные дразнилки? Какие есть расхожие ругательные мемы относительно различных технологий?

"Perl - writeonly язык"
"На PHP пишут только быдлокодеры"
"PHP тормозит"
"Postgres тормозит"
"Mysql бьет данные"
"Windows дырявая и небезопасная"

Что ещё?..

Коллективная разработка.

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

Первая вещь, которую необходимо внести в любой промышленных процесс — это формализованная система постановки задач и контроля их исполнения (трекер). Электронной почты для этого обычно недостаточно, она не доходит, теряется, остается не на том компьютере, две ветки переписки могут содержать противоречия, ключевые моменты в письме могут оказаться двусмысленными. Гораздо лучше завести отдельную систему (обычно с Web-интерфейсом), где и вести список задач и текущую ситуацию по ним. Как минимум, эта система должна позволять вводить суть задачи, какой-то её краткий идентификатор (заголовок или номер), текущего исполнителя (с возможностью сменить) и текущий статус (делается, сделана, отменена). Дополнительные поля зависят от реализации трекера, чаще всего используются приоритет, требуемый срок исполнения и какой-то рубрикатор по проектам, но фантазия и нужды авторов неисчерпаемы, бывает и многое другое. Так же абсолютно необходима возможность комментирования задачи. Типичный жизненный цикл задачи в подобной системе выглядит примерно так:
менеджер проекта ставит задачу на верстальщика перекрасить фон раздела в зеленый цвет;
верстальщик пишет, что в этом случае не будет виден шрифт заголовков — он сейчас зеленый;
менеджер дополняет задачу требованием изменения шрифта заголовков на красный;
верстальщик выполняет работу и пишет об этом в трекер;
менеджер проверяет исполнение и закрывает задачу (всё ОК).

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

Готовых систем существует достаточно много, большие компании часто пишут свои. Из доступных наименьшее отторжение лично у меня вызывает Trac, популярный альтернативы — JIRA, BugZilla, Mantis.


Вторая обязательная для использования система это система контроля версий (на практике наиболее популярны Subversion (SVN) или более старая CVS). Основная идея этих систем состоит в хранении и удобном доступе ко всем промежуточным версиям кода и возможности указывать комментарий при добавлении («коммите») новой версии. Главный плюс, который дает активное использование таких систем, это формализация понятия «код». Существенно меньше вероятность ситуаций «ой, тут не тот код, а тот был на флешке, а флешку я потерял», «ах, на сервере сейчас не то, а где то — непонятно, вот три разных варианта» и прочих катастроф неопрятности.

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

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

Третье важное для любого проекта ключевое слово - «шаблонизатор». В стандартном интернет-проекте программист на серверном языке пишет программу, результатом работы который будет HTML, подготовленный верстальщиком, с реальными данными вместо образца. Очевидно, что этот HTML должен быть спрятан где-то внутри программы и очень хочется добиться, чтобы верстальщик правил своё, а программист своё и они друг другу не мешали. Стандартным решением проблемы как раз и являются «шаблонизаторы». Идея в следующем. Верстка хранится отдельными файлами, написанными на псевдоязыке, с конструкциями типа ##Article.title##

##Article.text##, а внутри серверной программы есть блок, который надевает на эти шаблоны реальные данные. Верстальщик при этом легко вставляет HTML-теги в почти-html текст шаблона, а программист в теории может его вообще не касаться.

Для каждого языка программирования существует огромное количество стандартных шаблонных библиотек. Они отличаются друг от друга производительностью, легкостью в изучении, возможностями и популярностью (чем популярнее — тем лучше, проще вводить новых людей в команду). Идеального выбора ни под один язык, наверное, нет, всё зависит как от конкретной задачи (важна производительность или нет, важна легкость изучения или нет), так и просто от вкуса ключевых исполнителей. Часто говорят, что идеалом является XSLT, лично мне кажется, что это наоборот всегда плохой выбор. Иногда пишут собственные шаблонизаторы, с моей точки зрения, в 2009-ом году это однозначно лишняя трата времени.

Заранее спасибо за поправки!

Все наши серверные программы и базы данных должны крутиться на каком-то физическом железе. Принципиально есть две возможности: арендовать какие-то виртуальные ресурсы у хостинг-провайдеров (сколько-то гигабайт дискового пространства, такая-то доля процессорной мощности, столько-то доступной оперативной памяти) или покупать/арендовать собственные сервера. Первый путь очевидно оптимален в случае небольших проектов, второй — в нагруженных. Границу можно крайне условно определить где-то в 100000 обращений в сутки, но условность этой цифры, пожалуй, максимальна из всех возможных.

В случае виртуальных ресурсов все проблемы решает за нас хостер, если же принято решение о собственном/арендованном железе, то лучше представлять себе что это такое. 4 основные компонента сервера это корпус, процессоры, память и жесткие диски. Главная характеристика корпуса — высота при абсолютно стандартизованной ширине (19 дюймов). Высота измеряется целым числом «юнитов», 1 юнит равен 7/4 дюйма, примерно 4.5 см (или как часто шутят абсолютно точно соответствует старому русскому вершку). Сервера бывают «одноюнитовые», «двухюнитовые» и, реже, большеюнитовые. Чем больше в корпусе юнитов, тем больше в него помещается, но соответственно тем больше он занимает места в стойке провайдера и так или иначе, тем дороже он будет обходиться. Качество процессора определяется тактовой частотой и количеством ядер (чем больше — тем лучше), а так же потребляемым электричеством (чем меньше — тем дешевле). Общепринято, что в большинстве случаев оптимальный выбор это двухпроцессорные модели (а уж каждый процессор может быть многоядерным). Памяти должно быть, чем больше, тем лучше, она достаточно дешева и экономить на ней смысла нет.

Сложнее всего с дисками. Размер жесткого диска последние годы практически никогда не имеет значения, даже самые маленькие из них заполнить довольно сложно, но при этом диски всегда тормозят, и их скорость часто важнее скорости процессора. Сейчас популярны диски двух типов: SAS (быстрее и дороже) и SATA (медленнее и дешевле), апгрейдить один на другой в рамках одного корпуса/материнской платы обычно невозможно. Стандартный способ ускорения дисковой системы — увеличение числа используемых винчестеров, с тем, чтобы на каждом диске лежала какая-то своя часть активно используемых данных.

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

Ещё одна альтернатива классическому способу разработки — Flash. Как и Javascript, это язык программирования на стороне клиента, внутри браузера. В отличие от Javascript'а поддержка Flash'а не входит в стандартные поставки браузеров, а требует дополнительного плагина. Тем не менее, сейчас Flash стоит на подавляющем большинстве компьютеров, подключенных к Интернету (на мобильниках его нет). Более того, благодаря тому, что реализует его одна компания (Adobe), а не все производители браузеров — мне кажется, он получился более стандартизованным и проблем с поддержкой всех браузеров получается меньше.

Технически главное отличие Flash'а от Javascript в том, что если HTML ориентирован на текст и статические картинки, а Javascript на модификацию HTML, то базовые конструкции Flash'а — работа с графикой, в том числе анимированной. AJAX-подобная модель работы с сервером для Flash'а стандарт. Классические применения Flash'а — красивые анимированные баннеры или баннероподобные решения, youtube-подобные видеоплееры, игры, играющиеся непосредственно в браузере.

В принципе, на Flash можно делать всё, что угодно, но использование его для простых вещей (отображение текста, навигация, ...) обычно неоправданно, чем красивее буквы, тем их сложнее читать. Кроме того, важно помнить, что Flash-программисты — специалисты крайне редкие, большинство людей, указывающих в резюме слово «Flash» являются на самом деле Flash-художниками, профессия тоже важная, но программиста ни в коей мере не заменяющая.