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

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

Ну или запустить два инстанса — один (без ограничений) — для .onion

Трафик к onion-сайтам может идти через любые ноды, не важно exit или не-exit. Поэтому второй тор уж точно не нужно запускать.

А ведь вы правы. Если постоянно сидишь через VPN, то о блокировках гитхаба и прочем мракобесии узнаешь с хабра или от знакомых. Так ведь наша лень доведёт до того, что VPN банить начнут.

Аналогия понятна. Осталось понять, как соотносятся множества «автомехаников» и «автоконструкторов» (кого больше и как велико пересечение) и насколько прост переход между ними.

1. Если оставить в стороне I2P, то чем ваше решение превосходит Tor Browser, который запустить не сложнее, чем обычный браузер?
2. Пожалуйста, пишите Tor, а не TOR. Эта ошибка встречается в каждой второй статье, где упоминается Tor, поэтому не обессудьте, что пишу не в личку.
3. Скрытые сайты тора без анонимности можно просматривать через tor2web-шлюзы. Я писал про них и сделал один сам: припишите к адресу .gq и сайт откроется.

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

Это совет тем, кто с английским пока не дружит.

А для меня эта статья в первую очередь хорошо иллюстрирует пользу от тестов. Буду на неё ссылаться в качестве примера пользы от тестов в большом проекте.

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

Вот пример того, как тесты помогли найти источник тормозов в игре.

На C++ можно писать веб-сайты без Javascriptа.

А «приличный программист» не может в личиночной стадии быть «быдлокодером»?

Спасибо! У вас значительно быстрее получилось. (А Lua всё равно в 2 раза быстрее.)

Должен отметить, что код стал менее понятен, хотя я его по-прежнему могу прочитать «со словарем». Чтобы догадаться до такого решения, надо в Haskell как следует разбираться. К примеру, для меня остается загадкой, почему мой код работал медленнее. Могли бы вы объяснить?

есть простая библиотечная функция из 15 строк, рекурсивно удаляющая из указанного каталога файлы старше N дней

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

Перевод на русский был здесь, а картинка осталась.

ты не напишешь сразу код так, что он будет тестируемый.

Могу соврать, но вроде бы чистый TDD подразумевает написание сначала тестов, а уже потом кода. Сначала скажи, что хочешь от кода, а потом пиши код. Разумеется, это происходит не в масштабах всего кода, а только отдельных классов и функций. При таком подходе исключается возможность написать нетестируемый код :)

Ну и 100 процентное покрытие — это избыточная (иногда значительно) сложность — особенное если имеешь дело не со stateless приложениями.

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

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

В BitcoinJS тесты вместо документации. Эта библиотека используется в таких крупных проектах, как Blockchain.info. Мне кажется, что ответ на ваш вопрос включает почти все библиотеки и многие приложения. Можно даже писать тесты к сайтам: писать запросы и ставить проверки на ответы. Кроме того, TDD даёт однозначный ответ на вопрос «когда делать коммит» (когда дописали до момента, что все тесты проходят и ими покрыт весь код).

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

А что если взять ваш комментарий и заменить слово «Хаскель» на слово «Lua»? Тоже мало библиотек и программистов и эти программисты тоже призывают на Lua писать всё, а потом оптимизировать на C нагруженные точки программы. Звучит вполне разумно, благо Lua и C очень хорошо взаимодействуют. Дальше возьмите JavaScript — тот же Lua, но как язык похуже (с моей точки зрения), однако с огромным количеством библиотек и программистов. Почему бы не использовать «предпочтительно» скриптовые языки такого типа?

Для проверки я решил одну задачку на нескольких языках. Задачка решена на каждом языке наиболее понятным мне способом, безо всяких. Сама задачка хоть и счётная, довольно бесполезна, это просто первое, что пришло мне в голову. Так вот, на уровне сей справились Java, JavaScript, Python, Lua, JavaScript. Затем с многократным отставанием шёл Haskell, после которого ещё с трёхкратным отставанием Perl и Ruby. На Haskell получился очень красивый и короткий код, но писал я его дольше всего. Получается, программы на Haskell дольше пишутся и медленнее работают, чем на быстрых скриптовых языках. Опять же, в случае Lua было бы очень просто переписать это место на C, а в случае с Haskell я даже не знаю, что бы я делал. В общем, это претензия скорее к моему незнанию Haskell, нежели к самому языку.

На C++ можно написать эффективную реализацию. А если использовать шаблоны, то можно на массивах из double заткнуть за пояс сишный qsort. Это просто замечательно. Но к этому пришли не сразу. Представим, что быстрая сортировка — это наш новый алгоритм, который до нас никто в мире не реализовывал. Не думаю, что было бы правильно реализовывать его сразу на C или C++ в таком виде, как он реализован в стандартной библиотеке. Сначала надо было бы реализовать наиболее понятным способом. Затем протестировать, убедиться, что всё работает правильно. А потом, если эта понятная, но медленная реализация окажется узким местом, переписать на C, используя оптимизации. И снова прогнать тесты, чтобы не наляпать при этом.