Григорий Ситнин

Решение задач – это и есть дизайн. Некоторые наши клиенты, кстати, хуево слушают, поэтому бывает, что удивлены нашим нежеланием обсуждать получившийся дизайн. А дизайн не надо обсуждать, он в нашем случае является решением поставленной задачи. Обсуждать можно только одно: решена задача или нет.

Отсюда

Солидарен полностью.

Когда сайт Zend сталкивается с относительно редкими задачами — он дико тормозит, хотя использует все их примочки и стоит явно не на домашнем сервере.

Процедура смены пароля занимает прорву времени.

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

Стыдно должно быть так подставляться.

Отвечал в комментарии, но захотел вытащить в отдельный пост.

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

Таким образом, я пытаюсь указать тебе на то, что правило “не нанимать людей в середине проекта”, конечно, близко к истине, но истиной не является.

На вскидку, вот случай, когда это необходимо: потребности в рабочих руках были недооценены и рук попросту не хватает. Тогда можно нанять человека и за два дня до релиза (за один нельзя, починить что отвалится не успеете =).

Strive for perfection in everything you do.
Take the best that exists and make it better.
When it does not exists, design it.

По-русски будет так:

Добивайтесь совершенства во всём, что делаете.
Возьмите лучшее из существующего и улучшите.
Если этого не существует, создайте.

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

Insight IT, Архитектура Twitter

ППКС

Кто-нибудь тестировал производительность CLR-кода в Mono?

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

Установил к себе новую версию кросспостера в ЖЖ.

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

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

Кто-нибудь может посоветовать хороший Python/Django-хостинг?

Желательно, в России.