Евгений

У нас довольно примитивная система. Проект на Django, хранится в mercurial, есть две ветки: staging и production. Все изменения (за исключением совсем срочных багфиксов) по умолчанию идут в staging. При релизе изменения из staging пушатся в production, на сервере самописный shell скрипт выполняет pull и перезапускает сервер. Скрипт запускается вручную.

Еще используется buildout, который управляет всеми зависимостями проекта, два конфигурационных файла. В окружении разработчиков используется конфигурация, в которую включены django-debug-toolbar, в которой определены безопасные умолчания (например, использование песочницы PayPal вместо настоящего аккаунта PayPal, и т.п.). На сервере используется конфигурация без средств отладки.

У меня ноутбук с AMD/ATI. Не рекомендую. Видео греется как печка даже при обычной работе, при этом раскаляя все внутренности ноута, в т.ч. повышая температуру процессора и жесткого диска. Особенно при использовании открытых драйверов (подшаманивание с целью включить энергосбережение привело к суровым глюкам, но ни на градус не снизило температуру).

С Catalyst чуточку получше, но они тоже очень глючные. Во-первых, ноут все равно почти все время нагревается выше нормы, особенно во время просмотра фильмов. Во-вторых, в фильмах периодически видны артефакты в виде дергания и горизонтальной полосы (что-то не так с вертикальной синхронизацией, эта проблема отсутствует в открытых драйверах, и не лечится никакими настройками в Catalyst). В третьих, тупой Catalyst отказывается понимать секцию InputDevice в xorg.conf для моего трекбола (там всего лишь настраиваются дополнительные кнопки, никакой эзотерики) и вылетает. В четвертых, с Catalyst перестают работать suspend и hybernate (точнее работают, но через раз, через два происходят зависания, а это все равно, что не работают).

В общем, горько жалею, что взял ноут с ATI и посылаю лучи ненависти криворуким программистам AMD.

revelation с файлом паролей в Dropbox.
Пароли от revelation и dropbox заучил на уровне рефлексов, чтобы вслепую пальцами набирались.

Покупаю в Amazon. Дорого, но учитывая, что я заказываю там 2-3 книги в год, душу жабу. Зато доставка буквально через 3 дня или около того прямо до двери квартиры.

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

Я использую программу duplicity, а копии храню на Dropbox (duplicity также поддерживает S3, ftp, samba, scp). Плюсы — автоматические зашифрованные (пароль прописан в скрипте) инкрементальные (можно восстановить предыдущие версии файлов, и бэкапы занимают меньше места) копии.
Минусы — не уверен, что duplicity работает под Windows.

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

Видел, но не использовал: www.quirky.com/products/64-Plug-Hub-Desk-Power-Cable-Organizer
По-моему, неплохо придумано.

workrave — во вкладке «Статистика» есть пробег мыши.

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

Расширение для firefox на основе ScrapBook? Если сам ScrapBook не подходит.

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

Кэширование — это очень сложно. Если у вас вносятся изменения в БД, то появляется масса проблем с инвалидацией. Инвалидацию очень легко забыть где-нибудь вставить, даже если с этим помогает фреймворк/ORM.

Все «полностью автоматизированные» решения по кэшированию, создавали гигантские проблемы, потому что в каких-то случаях не инвалидировали кэш, когда нужно. Допустим, есть объект Profile со свойством balance. Пользователь покупает услуги, генерируется invoice, и либо баланс показывается закэшированный, либо инвойс не появляется в списке закэшированных инвойсов. Оба случая вызывают неистовое негодование пользователей, поверьте моему опыту.

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

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

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

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

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

Мне помогает соблюдение режима и план на день. Вставать и ложиться в одно и то же время, после подъема начинать работать, без промедлений (максимум — зарядка, завтрак, душ), и по плану вида:
— проект 1 — 2 часа с 9:00 до 11:00
— проект 2 — с 11:00 до 15:00
— перерыв 2 часа

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

Первым делом я бы проверил железо. В ubuntu в загрузочном меню есть memtest86. По опыту могу сказать, что некоторые ошибки проявляются спустя полчаса тестирования (зависит от скорости процессора и памяти, а также ее объема), у некоторых, слышал, спустя сутки тестирования.

Дальше запустил бы strace на падающие команды.

Еще слазил бы вручную на сайт packages.ubuntu.com, и если там есть более новая версия libc, попробовал бы скачать и установить ее вручную (dpkg -i, если dpkg не падает).

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

В PostgreSQL 9.0 High Performance не рекомендуется использовать SSD из-за того, что на них всегда присутствует write cache в том или ином виде и практически не гарантируется целостность данных при внезапном отключении питания. Данные пишутся на SSD большими блоками, большими, чем размер блока файловой системы, поэтому контроллер должен кэшировать записываемые данные в любом случае. И ни один производитель SSD не гарантирует, что данные будут записаны полностью после выполнения fsync или при отключении кэширования. SSD может проигнорировать все подобные попытки.

В качестве файловой системы там рекомендуется XFS. Пишется, что это почти то же самое, что ext3 в режиме writeback по надежности, но немного быстрее (там приведены результаты бенчмарков автора).

Вообще, рекомендую почитать, там много ценной информации и по выбору дисков, и RAID, какие подводные камни есть в каждом случае.

В моем случае проект был написан «абы-как». Точнее, довольно грамотно, но без каких-либо мыслей о том, что пользователей станет много, и придется как-то масштабировать. Более-менее красивый код, куча таблиц, связанных друг-с-другом, то есть чуть ли не десятки JOIN'ов. Кэширование не использовалось вообще.

Все работало (и работает) на 3-х серверах: база PostgreSQL, nginx для статики, nginx с gunicorn для собственно приложения.

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

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

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

Работал в компании, где были ежедневные письменные и устные отчеты заказчику из США.

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