mithraen

Если считать отношение, то будет проблема с делением на ноль.
Логичнее тогда уж считать разницу между счетом деленную на сумму счета.

Тогда у проигравшего будет отрицательный результат.

Недостаток этой системы будет лишь в том, что счет 0:1 и 0:100 приведет к идентичному результату в рейтинге.

1. Как писать автотесты — зависит от средств разработки. Скрипты на perl, десктоп приложения на Qt, и серверные приложения на Java тестируются, очевидно, по-разному.

2. Как делать описания тестов (для тестировщиков) — для этого нанимается опытный тестировщик, который сам все объяснит.

3. При работе с git — коммитить желательно отдельными логическими изменениями. Желательно перед коммитом проверять компилируемость. Не стоит крупные изменения делать одним коммитом, лучше разделять — вот сделали подсистему, вот мы ее используем в этом модуле, вот — в другом. Если какая-то функциональность развивается долго параллельно другой деятельности — git rebase позволит команде которая занимается этой подсистемой синхронизироваться с остальными, но не отправлять свои изменения пока не закончит работу. А потом отправить сразу группу коммитов.

4. Как настроить среду на кодинг — я не думаю что получится установить это как стандарт. У каждого программиста свои привычки. Идеальной настройки emacs/vim не существует.

5. По поводу DE — я лично фанат xmonad. Многие tiling WM не выносят, и для них он не подходит. Я не понимаю почему — но это факт. При найме программиста мне важно как он пишет код, а не какой window manager использует.

6. Тут вот какая штука — в Linux легко организовать миграцию конфигов. Так что даже при использовании парного программирования элементарно обеспечить чтобы каждый работал с привычной ему средой.

Стандартизировать надо не window manager, а требования к оформлению кода.
Возможно даже используемые в интерфейсах цветовые схемы и шрифты — чтобы при парном программировании люди глаза не ломали. Но и тут я бы поостерегся, а скорее предоставил возможность людям тратить некоторую часть рабочего времени на тюнинг. Тогда они будут интересные идеи по настройке рабочего места утаскивать друг у друга. Результат будет лучше чем любой стандарт.

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

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

Просто звоните в их колл-центр и говорите что едете туда-то и не хотите чтобы вашу карту заблокировали.

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

Есть Sphinx: cmusphinx.sourceforge.net/sphinx4/

И для него есть даже поддержка русского языка, более-менее работоспособная.

Главная проблема в том, чтобы определять начало/конец команды, а также наличие фоновых шумов в комнате.

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

Если же just for fun, вам хочется сделать очень быстрый движок, и именно это является основной целью — только тогда есть смысл браться и писать его.

1. Используйте аналог SSI от nginx для сборки страницы из нескольких кусков. Это позволит сэкономить на записи (большая часть контента будет статична, и часто обновляться будут в основном навигационные элементы).

2. С раздачей статики великолепно справляется nginx, и упираться он будет исключительно в ширину канала и скорость дисковой подсистемы.

3. Следовательно, чтобы исключить влияние дисковой подсистемы — используйте сервер с SSD (они уже доступны), также часть, или даже весь контент можно дублировать в tmpfs.

4. Часто изменяемые данные (например список новых материалов на форуме, и т.д.) есть смысл держать в memcached. Благо nginx умеет раздавать прямо из memcached.

5. Выбор языка для разработки тут не существенен, на самом деле. А задача объемная. При этом раз вы завязываетесь на nginx со специфическими настройками — все равно «обычный хостинг» уже не подходит. А следовательно вы можете выбирать любой язык разработки, исходя из того на чем такое решение писать будет лучше. Ограничиваться PHP не обязательно.

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

Можно, если ваш бюджет на рекламу сравним с таковым у Google.

Уже есть Wordpress, Drupal, Joomla, Typo3. Они хороши тем, что есть огромное community, и ставя их я уверен, что всегда недорого найду сотрудника, который решит любую мою задачу.

Поставив закрытую CMS я буду иметь проблемы. Которые решать будет дорого и геморно. Тем более если этой закрытой CMS пользуется мало людей — зачем мне быть подопытным кроликом за свои деньги?

Плюс на этом рынке конкурировать придется с Битриксом. А бюджеты 1С на рекламу немаленькие.

Коммерческая закрытая CMS сейчас может окупиться только если это SaaS.

1. Совместимость с C/C++
— написание библиотеки на D, используемой из C/C++
— использование из D библиотеки на C
— использование из D библиотеки на C++

2. Доказательства того, что это хорошая замена именно C (компактность)
— примеры кода, начиная с hello world на D и C, сравнение у результата вывода ldd и размера бинарника :)

3. Применимость на классических задачах, на которых хороши языки высокого уровня:
— работа с regexp'ами (сравнение с perl)
— работа с БД (сравнение с JDBC, perl DBI)
— простой HTTP-клиент
— простой HTTP-сервер

4. Управление процессами
— запуск процесса, перехват stdin/stdout/stderr

5. Написание GUI-приложения
— варианты простых диалогов на gtk

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

Найти решение проще будет сложно.

Postini это дополнительный сервис. В беслптном google apps предлагается ровно тот же уровень защиты от спама что в обычном аккаунте gmail.

И да, папка «спам» самообучается. Поэтому очень важно спам не удалять, а помечать как спам. Соответственно найденные в папке «спам» нормальные письма переносить оттуда соответствующей кнопкой.

Со временем почтовик будет ошибаться все реже.

1. Утилита mysqltuner поможет настроить сам mysql
2. С помощью explain посмотрите используются ли индексы при выполнении запросов
3. Ваша проблема наверняка связана с тем, что не созданы нужные для ускорения конкретно ваших запросов индексы.

Подсказать что-то большее можно уже только увидев структуру БД и сам запрос.

Также рекомендую книгу Мартин Грабер «Понимание SQL». Там очень много ценного про оптимизацию запросов есть.

Много списков дел — гарантия проблем. Эти списки следует рассматривать не как «дела», а как «inbox» (см. Getting Things Done).

Список же дел надо иметь один единственный, возможно синхронизируемый между разными устройствами.

Есть дела жестко привязанные ко времени (т.е. у них есть дедлайн, и при этом на них нельзя забить). Если дедлайн есть, но забить можно — это не дедлайн, жизнь так устроена что не все задачи выполняются, некоторые — отменяются. Поэтому задачи с жестким дедлайном, но которые можно проигнорировать пишутся в общий TODO-лист. Жесткие же задачи пишутся в каледарь (google calendar, например).

Для всего остального можно использовать систему «автофокус» Марка Фостера. Это проще чем внедрять GTD.

Распорядок дня, в котором указано время работы по «автофокусу», а также время работы над ключевыми долгосрочными проектами. По ним списки дел удобно иметь отдельные.

Посмотрите на Evernote. Для хранения сопутствующей информации самое то.

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