Глаза могут не уставать потому что у Вас хорошие глаза, хорошее общее самочувствие, хорошоее освещение, хорошие шрифты на экране, не очень много сидите за компьютером.
fflush(stdout) надо после fprintf(stdout).
я думаю если stderr вместо stdout помогает — в этом причина.
но раз на 1000 идёт расхождение — где-то ещё есть баг.
я не смотрел где ещё есть баг, заострил внимание только на влиянии ">" на результат.
Или например генерация xml — очень сложная часть. Тогда нужно будет написать несколько тестов (скажем 10), который проверят как генерируется xml в разных случаях. Зачем тогда заводить 10 фикстур в БД? Если они ни для чего не нужны, кроме тестирования этого метода + отличаются только парочкой полей…
Это не избыточность. Юнит тест тестирует каждую функцию кода отдельно.
Ответ ниже подходит, если все эти условия выпоняются: 1) в нашем приложении мы решили не подделывать вызовы к БД, а использовать фикстуры и настоящие вызовы. не во всех языках и фреймворках принято так делать. 2) нас устраивает фикстура для записи 123, в ней содержутся все поля которые будут в XML 3) SQL извлечения записи по ID — простой и его нельзя реализовать криво, например использовав не тот индекс (ну да в данном примере так и есть) 4) Мы в общем то не будет усложнять этот метод добавлять туда кэширование например или усложнять запрос, у нас так же нет похожих но более сложных методов.
Так же ответ ниже подходит если пишется не Unit тест а интеграционный. Или вообще пишутся какие-попало тесты, не заостряется внимание на следованиям методологиям.
Управление релизами — Раз код пересекается, хранить в одном репозитории.
Иметь скрипты которые будут делать релизы отдельно каждого компонента. У них будут версии.
Думать головой и следить какие версии с какими совместимы (например менять мажорный номер версии при несовместимости,
документировать API компонентов, обеспечивать обратную совместимость компонентов)
Т.е. одним словом — система управления версиями тут не причём.
Вообще из описания не на 100% понятно в чём именно задача.
Нет, принципиальная разница. У rdiff будет столько же файлов в destination directory, как и в source directory. Так же удаление при ротации кучи файлов очень затратная операция.
Файловая система NTFS — case preserving, case insensetive.
На счёт того что причины в древности платформы — не уверен. HSFS+ MacOSX тоже не чувствительна к регистру.
А linux попросту не имеет понятия «кодировки» файлов, поэтому при всём желании не сможет найти соответствие между большими и маленькими буквами.
Если у в Glacier всего террабайт, то скачать весь террабайт сразу будет очень дорого.
Около $2k если скачать за 4 часа или $300 если за 24 часа, или $20 если скачать за месяц.
Glacier лучше использовать как secondary backup. И иметь возможность скачивать не срочно нужные данные в течение долгого времени.
Например семейный фотоархив может подождать месяц. А может и подождать два года, тогда вообще восстановление будет бесплатно.
1 Tb лучше конечно ингрементально бэкапить, даже с точки зрения ввода-вывода жесткого диска.
Чтобы их раскрыть нужен именно исходник? Неужели сотрудник, имеющий отношение к программированию не может догататься о ключевых моментах технологии без кода?
Обычно ответ на этот вопрос — «нет», если только вы не разрабаывает что-то сверхестественное, наукоёмкое итд (что не так даже для большинства проектов, захвативших большую долю рынка).
Хоть раз здесь на хабре кто-то раскрыл какое-то ноу-хау (и при этом было не очевидно с согласия ли владельца фирмы или нет)?
Вы предаставляете сотрудника получающего достойную зарплату, достойного специалиста, подписавшего NDA выложившего на хабр ради прикола технологию?
ИМХО это исто ментальная проблема (если нет объективных обстоятельств о которых мы не знаем). Свой код всегда хочется защитить. Хотя на самом деле код — наименее ценная часть проекта.
У меня и ещё у кучи фрилансеров были исходники сайтов, которые у всех на слуху ежедневно. Никому нет дела до этих исходников.
