Alex Efros

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

На мой взгляд с Вашим опытом имеет смысл выбирать между Ubuntu и Gentoo. Первое если нежелание вникать в проблемы сильнее желания всё настроить под себя, второе в обратной ситуации.

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

Мы используем asciidoc. Ваши пункты 1-5 умеет из коробки, просмотр через веб-сайт делается через тривиальный скрипт (можно взять мой asciidoc.cgi). Вот статья «Использование asciidoc для документирования проекта».

Мне в своё время очень помогла разобраться с тестированием книжка Perl Testing: A Developer's Notebook. В подходе к тестированию особой разницы между Perl и PHP нет, так что Вам она тоже может оказаться полезна. Перевода, к сожалению, я по-быстрому не нашёл, возможно она есть только на английском.

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

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

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

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

Судя по контексту, Вас интересует анонимность, а не безопасность.

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

Именно от имени этой личности Вы будете выкладывать в сеть всю необходимую информацию — имя и контактную информацию для клиентов/знакомых, адрес и кредитку для магазинов, фотки для друзей. Вы можете пытаться контролировать объём выкладываемой информации, ограничивать своё присутствие в социальных сетях, и т.д. — но это не даст большого эффекта: всё, что Вы не расскажете про себя сами, про Вас расскажут Ваши друзья. Избежать этого можно, только если у Вас нет друзей, Вы не делаете покупки в интернете, не ищете через интернет работу, не пытаетесь заработать деньги через интернет, … что для большинства абсолютно неприемлемо, так что лучше сразу смиритесь с тем, что «реальный» виртуал у Вас всё-равно будет. Единственный возможный способ его «анонимизировать» это не привлекать к нему внимания — сделайте так, чтобы эта «реальная» виртуальная личность абсолютно ничем не выделялась на общем фоне, будьте «как все».

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

1. придумайте полноценную личность — имя, ник, пол, email, …
2. используйте для всей деятельности от имени виртуала другую OS (в идеале не просто ещё одну винду/линух в VMware, а действительно иную OS, с другим набором используемых приложений — другой браузер, IM-клиент, etc.); может иметь смысл использовать специальные дистрибутивы линуха ориентированные на максимальную анонимность
3. настройте эту OS не так, как обычно настраиваете свою систему — другой язык, другое разрешение экрана, другая тайм-зона
4. по возможности используйте другой канал для выхода в инет (напр. если основная система работает через городскую локалку или ADSL, виртуальная система может работать через публичный WiFi)

И только когда эта часть Вашей анонимизации готова, можете начинать заботиться о VPN, Tor и proxy. Конечно, ещё остаётся вероятность, что Вас всё-равно вычислят по психологическому профилю… :-) но чтобы кто-то начал сравнивать псих.профили Ваших виртуалов сначала должно появиться подозрение, что эти виртуалы принадлежат одному человеку, а для этого скорее всего Вам необходимо будет самостоятельно проговориться или ошибиться (указать не тот email, или выйти в инет не через тот канал, etc.).

DISCLAIMER: Поддержка полноценной не отслеживаемой виртуальной личности может со временем привести к психическому заболеванию. :)

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

Я бы порекомендовал вместо поисков «что можно» и «что нельзя» изучить «как надо» работать с потоками вообще. А потом, уже понимая что Вы хотите получить, изучать как именно нечто подобное можно сделать в третьем питоне. А «надо» с потоками работать в стиле CSP — это самый простой подход, превращающий многопоточное программирование из очень сложной, запутанной и глючной. К сожалению, он подразумевает использование действительно большого количества потоков, что невозможно если каждому потоку выделять довольно большой стек (что делают практически все реализации потоков в разных языках и ОС). Поэтому «пощупать» это можно, например, на языке Go, или на stackless питоне.

Использование asciidoc для документирования проекта

Поскольку решения, идеально подходящего для обеих ОС нет, то правильный ответ зависит от того, какая ОС используется больше. Если больше используется Linux, тогда раздел лучше сделать в ext3, а для доступа из винды использовать драйвер Ext2IFS (при форматировании раздела надо явно задать размер inode 128). Если больше используется винда — тогда раздел в NTFS и встроенная в Ubuntu поддержка (вероятно, через ntfs-3g).