Прочитал на днях вот эту статейку: http://www.dwheeler.com/essays/filenames-in-shell.html. Это просто жесть. Я наверное не видел ни одного баш скрипта, который бы делал все правильно, как там описано. Не легче ли использовать какой-нибудь там питон для этого, а не терпеть внезапные унижения собственным шеллом, когда ты впервые запустишь скрипт на файлах с русскими символами / пробелами / переносами строк / еще какими-нибудь внезапными названиями?
ну, что-то типа проксмокса, например, но чтоб можно было быстро развернуть виртуалки, которые должны сами вешаться, возможность использовать несколько сетей, виртуалки при установке должны сами настраиваться на нужную сеть, при этом, не контейнерная, а хардварная виртуализация
Тут много раз слышал про всякое там тестирование программ, чтобы убедиться, что они работают как надо. Так вот я тоже стал делать нечто подобное для своих этих октодеревьев для вокселей.
Суть в том, что библиотека делает в основном некие вычисления (математические), правильность которых нужно проверить. Моё видение тестов такое: если там вдруг после некоторого коммита резко станет неправильно работать некоторая функция, и программа будет падать - на это начихать с точки зрения тестирования. Главное, не пропускать «тихие» ошибки, когда функция вроде как отработала, но вернула неверный результат.
И я накатал такие тесты: построить дерево и проверить, правильно ли оно построено. Потом ещё в для каждого алгоритма поиска делается проверка с простейшим алгоритмом перебора (сложности O(n)) и сравнением результатов.
В основном это тесты, проверяющие некоторые математические свойства этих деревьев. А как делают настоящие программисты? Что именно тестируют? Ещё что-то слыхал про инструменты автоматического юнит тестирования. Это как?
И вопрос не совсем по теме:
Ещё есть некие бинарные операции, хотелось бы проверить некоторые их свойства (ассоциативность, например). Для этого придется проверять на равенство 2 предположительно равных floting point значения, полученных разными способами. Как правильно это сделать?
kcachegrind - простая как топор смотрелка логов callgring, ей НЕ нужны активитис, вывод звука, 50 метров иконок, поисковый индексатор с метаданными и прочая хренота. Тем не менее:
размер программы: ОДИН мегабайт. Бесполезных зависимостей: 157 мегабайт. Хлама в 157 раз больше самой программы! Я всё понимаю: места на диске много и т.д. и т.п., но должны же быть хоть какие-то рамки. Почему бы не линковаться тогда сразу с либреоффисом или квейком, гулять так гулять.
Между тем, вот отсюда скачиваются сорцы практически тоже самой программы в версии, где до них не добралась рука безумного кедового маркетолога. И после компиляции получаем бинарник qcachegrind, который зависит — совершенно верно — только от Qt. Как оно и должно быть.
(Собственно, чего я их скачивал-то: чтобы исправить неприятный баг. Но это к теме отношения не имеет.)
Чего я хочу сказать? Да уже давно не хочется ничего говорить. Хочется убивать.
Что будет полезно почитать после того, как выучил объектно-ориентированный язык и пару технологий? Дискретную математику? Что-нибудь по алгоритмам? Книги по объектно-ориентированному дизайну/анализу? SICP с лиспом? Ваши варианты.
26 марта вышел терминальный мультиплексор tmux 1.8.
Данная утилита позволяет одновременно работать с несколькими приложениями в рамках одной удалённой сессии/открытого окна терминала, что незаменимо для системных администраторов и простых пользователей консольных приложений.
