• В разработке — каждый сам за себя. Но иногда это приводит в тупик
    +3
    Никто же не говорит писать говнокод.
    Просто сидеть и придумывать идеальную архитектуру не написав ни единой строчки кода тоже не вариант.
    Нужны итерации, пускай даже для себя.
    Так должна вырисовываться хорошая архитектура.
  • В разработке — каждый сам за себя. Но иногда это приводит в тупик
    +2
    Мне кажется здесь очень хорошо подходят слова Кента Бека «Make it work, make it right, make it fast».
    Многие вещи, о которых сразу и не подумаешь выползают уже на реализации. И наоборот, то чего сильнее всего опасался вообще не будет играть большой роли.
    Сидеть и теоретизировать до бесконечности придумывая идеальное решение тоже не выход. Зачастую реализация может подсказывать пути хороших решений.
    Так что нужен баланс.
  • Особенности и отличия языка программирования MSH от MUMPS
    0
    В MUMPS переменные хранятся в деревянной структуре

    Откуда такой термин? Может все же «Древовидной»?
  • 9999+ сохраненных на потом
    +3
    Сохранил в закладки, что б прочитать потом
  • 27 лет арктических льдов за одну минуту
    0
    а не в Америке или США

    Что?
  • Тесты, которые тестируют тесты
    +1
    Естественно, применяя правильные подходы, можно добиться того, что с тестами вероятность наличия ошибки в коде будет близка к нулю.
    И на практике этого бывает более чем достаточно.
    Но тесты в отрыве от других методов, сами по себе, не дают оснований говорить что в коде не содержится ошибки. Это нужно принять и использовать их в повседневной практике.
    Просто иногда тесты дают ложную уверенность в правильности кода.

    Протестированная программа != правильная программа.
    Вот и все. Это нужно понимать и помнить. И тестировать свой код. :)
  • Тесты, которые тестируют тесты
    +1
    Я не говорю, что тесты ничего не проверяют.
    Я целиком за тестирование.
    Просто корректность (с математической точки зрения) и корректность с пользовательской (соответсвие ожиданиям) это на мой взгляд разные вещи.
    Автоматизированные функциональные тесты отлично подходят для тестирования пользовательских сценариев.
    Модульными и интеграционным тестами можно покрыть класс или библиотеку так, что на любых практических данных все будет работать безошибочно.
    Но к корректности (алгоритмической если хотите) это будет иметь не слишком много отношения.
    А что касается практики, то только тесты могут давать некоторую уверенность, что основные, наиболее часто используемые моменты небыли упущены программистом.
    Я совсем не за то чтобы формально доказывать корректность любой программы. Совсем наоборот. Просто нужно понимать, что если ты покрыл программу тестами это вовсе не означает, что в ней нет ошибок.
  • Тесты, которые тестируют тесты
    0
    Если проводить аналогию с современным состониянием процесса тестирования, то книга Майерса близка к фаззингу и отладке:
    Напишите тест, который приведёт к нестандартному состоянию.
    Начинайте отладку программы (не тест начинает отладку, а инженер).
    Выясняйте в чем ошибка, исправляете (не тест ищет ошибку, а инженер).

    Фаззинг важен. Несомненно. Писать проверяющие корректность тесты, трассируя код лишь в уме, стало привычнее, чем постоянно фаззить и погружаться в отладку.

    Не знаю. Я из книги извлек несколько другое.
    Есть сценарии которые приводят к ошибкам. Нужно уметь работать с такими вариантами.
    Есть сценарии которые соответствуют нормальной работе. Нужно проверить что на некоторой группе значений все работает как и ожидается.
    При этом об отладке здесь никто не говорит вообще.
    Просто даются советы о выборе тестовых наборов.
  • Тесты, которые тестируют тесты
    0
    В крупных проектах цель автоматических тестов именно в проверке корректности. Чтобы коллега, сливая ветки, и задевая код, написанный не им, получал некую увереннсть — код в тестируемых ситуациях остался рабочим.

    Не совсем согласен. Уверенность получается за счёт того, что есть некоторый набор критериев, позволяющий проверить что остальная часть системы осталась незатронутой и по прежнему работает так же как и раньше с точки зрения имеющихся тестов.
    Мы не корректность проверяем, а проверяем не внесена ли ошибка в уже проверенный код.
  • Тесты, которые тестируют тесты
    +2
    Полностью согласен.
    Тесты это помощник в поиске ошибок.
    Плюс позволяют обнаружить появление ошибки в уже проверенной части при внесении изменений (естественно если на ошибки такого рода уже есть тесты)
  • Тесты, которые тестируют тесты
    +1
    А я и не говорю, что тесты панацея.
    Но они позволяют сократить время на локализацию проблемы.
    А что отладка, что тестирование параллельных процессов это не тривиальная задача.
    Просто когда есть уверенность в том что простые варианты проверяются тестами можно сосредоточиться на сложных.
    Если ошибка получается из-за банальной опечатки при правки кода, то тесты это быстро отловят, а если проблема с тонкостями многопоточности то тут только человек
  • Тесты, которые тестируют тесты
    +1
    Я наверное слишком сильно расписался выше.
    Идея тестирования вообще не в том чтоб доказать корректность.
    Идея как раз наоборот найти ошибки.
    Тестирование это вообще не про корректность.
    Вот что я имел в виду.
  • Тесты, которые тестируют тесты
    +1
    Т.е. тестирование в принципе можно рассматривать как «альтернативу» отладке.
    Как с алгоритмами: либо тратишь память (сохраняешь уже вычисленное) — меньше вычисляешь, не тратишь — приходится пересчитывать каждый раз заново.
    Так и здесь: пишешь тесты — меньше, проще и сразу понятно где отлаживать, не пишешь — тяжело локализовать место ошибки, тратишь кучу времени на исправление.
    А как бонус идет то, что тесты можно использовать и через месяц и через год, а отлаживать придется каждый раз заново с нуля.
    Естественно тут тоже не без проблем: тесты как и основной код нужно поддерживать в актуальном состоянии, что требует дополнительного времени.
  • Тесты, которые тестируют тесты
    0
    Предлагается вместо формального доказательства корректности каждого шага в программе, сделать тест, который что-то там проверит.

    Цель тестирования не доказательство корректности, а поиск ошибок. Т.е. чем больше потенциальных ошибок будет находиться при тестировании тем лучше. Ошибок коде может и не быть, но тест проверяет их наличие в потенциально опасных местах (на границах диапазонов, внутри, вне и т.д.).
    После осознания этого факта я стал немого по другому относиться к тестам.

    З.Ы. Советую почитать классическую книгу Майерса «Искусство тестирования программ», там проблема тестирования и доказательства корректности хорошо описана.
  • Dell готовится к приходу процессоров ARM в серверы
    +1
    > параллельно существуют две основных архитектуры – х86 и RISC.
    С вашей точки зрения получается тогда можно и так написать?
    «Параллельно существуют несколько способов получения бинарного кода из файла исходного кода на языке C++ – gcc и транслятор языка C++»

    RISC и CISC это принципы построения архитектуры команд, х86 — одна из возможных реализаций.
  • «Левада»: только 5% граждан РФ считают недопустимым ограничение информации в интернете. Наш альтернативный опрос
    0
    Краснодар, 32.
    Все три вопроса.
  • Пара полезных исключений из правил по форматированию исходного кода
    +3
    Ну про экономию отступов я понял из статьи:
    Ведь уменьшение на несколько отступов в глубокой лесенке очень помогает.


    Но проблема как раз в том, что конструкция не читается как один смысловой блок.
    Если это форматирование не вызывает у вас дискомфорта, попробуйте пару раз, возможно вам это понравится.

    У меня глаза начинают плакать кровью при виде этого :)

    В ваше продолжение — это все равно что в книгах отменить красную строку для абзацев (ну или отступы между ними), и догадываться об их окончании по тому как завершилась предыдущая строка.

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

    Не вижу связи с целостностью восприятия.

    У каждого языка есть style guides. И большинство программистов изначально ориентированно на них.

    Ничего личного, просто подобные велосипеды заставляют «спотыкаться» при чтении кода, вынуждая понять «следующий уровень восприятия» :)
  • Пара полезных исключений из правил по форматированию исходного кода
    +10
    И то и другое — вредные советы.
    Зачем нужна эта экономия в один отступ? Монитор 15"? Или 80-ти символов не хватает?

    В первом случае возникает стойкое ощущение, что просто-напросто потеряна then-часть условия.

    Во втором вы сами написали в комментарии к коду:
    Это не опечатка, два if один за другим и без отступа!

    Т.е. даже вы понимаете, что большая часть программистов воспримет это именно как опечатку.
    И как уже выше указал x0rHamster:
    Иногда избежать лесенки можно с помощью обращения условия

    ИМХО это единственный допустимый вариант сокращения.
  • О чем НЕ говорят разработчики или 7 любимых выражений программистов
    0
    Странно. Я-то думал, что сейчас уже писать свой код не подрывая его хотя бы минимальны набором тестов не принято :)
  • О чем НЕ говорят разработчики или 7 любимых выражений программистов
    +1
    Здесь нужно разделить модульное/интеграционное тестирование и функциональное.
    В первом случае тестирование всецело лежит на программисте, это его зона ответственности.
    Во втором — тратить силы разработчика на проверку всех возможных вариантов поведения пользователя нерационально, разработчик должен проверять основные usecase'ы, а для всего остального и предназначен отдел тестирования и QA.
  • Антивоенный Open Source
    +3
    ИМХО, вы бежите впереди паровоза. Еще ничего не создано, а вы уже лицензии изобретаете.
    Наоборот нужно радоваться, что исходники будут открытыми. Ведь DARPA могла вообще оставить результаты всех участников у себя.
    Так что ИМХО, нет веских причин для беспокойства. Современный мирный космос тоже вырос изначально работая на военных.
  • .NET 4.5 — обновление на месте .NET 4.0
    0
    Понятно.
    А то я почему-то подумал про .NET 4.5.1 и VS 2013
  • .NET 4.5 — обновление на месте .NET 4.0
    0
    > VS 2011
    А что за странная версия Visual Studio :)
    Может все таки 2013?
  • Зачем пользователи GIT-а редактируют свои коммиты
    +1
    Не хочу разводит холивор, но в Mercurial для таких вещей есть MQ :)
  • Как почти забесплатно получить диплом магистра от университета Карнеги Меллон по Software Engineering
    +4
    Какой-то ваш Иннополис подозрительный.
    В вехнем меню ссылка на конкурс 2013 для подготовки будущих сотрудников и преподавателей (http://innopolis.ru/university/konkurs_2013/).
    Критерии отбора кандидатов:

    >- навыки программирования «в малом», а также использования императивного блочно-структурированного
    > либо объектно-ориентированного языка: Java, C++, Ada или C;

    Что это такое программирование «в малом»?

    >- сравнительные языки программирования;

    WTF? гугл тоже не в курсе.

    Очередной распил?
  • Техника: Составление методов (рефакторинг М. Фаулера)
    +1
    У вас в 7 примере «Удаление присвоений параметрам» перепутаны имена amount и value.
  • Объектно-ориентированный анализ и проектирование
    0
    А как на счет электронной версии книги?
    Планируется ли вообще издание в цифровом формате.
  • Жизнь насекомых, или Как мы ловим «баги» в обновлениях антивирусных баз
    +2
    >За последнее время у нас было 2 серьезных инцидента с обновлениями (в декабре и в феврале)
    Было бы интересно прочитать подробней о причинах с технической точки зрения (если это конечно не коммерческая тайна).

    P.S.
    >«фалсы» и лост-детекты.
    > «падучесть»
    Очень тяжело читать такой текст, прям глаз режет.
  • Simple-Science — Простые опыты (дайджест #10)
    0
    Новая заставка получше предыдущей, только вот описание опыта можно немого подольше оставить, иногда приходиться отматывать, чтобы дочитать :)
  • Механические клавиатуры
    0
    Если честно вообще попал на них случайно. Залил пивом предыдущую, и зашел за новой в ближайший магазин. Ассортимент был не велик, но потом о покупке ни разу не пожалел. Сразу пошла как влитая. Теперь с трудом представляю, чем заменить за приемлемую цену.

    >Но я ничем другим, кроме как выбранной из нескольких таких, пользоваться вообще не могу.
    Да, я тоже думал, что к любой клавиатуре можно привыкнуть, но оказалось, что разница действительно есть. Плюс тут классическая раскладка, без всего лишнего, и удачный баланс усилия нажатия и чувствительности.
    Хоты возможно просто у меня была удачная партия.
  • Механические клавиатуры
    0
    Вполне возможно, тут просто личный опыт.
    Была закупка 3 шт. PS/2, потом 2 шт. USB, не очень хорошие. Потом опять PS/2, и вновь удачно.
  • Механические клавиатуры
    +2
    Отличная клавиатура. Сам пользуюсь уже несколько лет. Очень нравится ход клавиш и усилие нажатия.
    Правда сейчас в продаже пошли в основном USB (KFKEA4XY), но у них почему-то нажатие оказалось несколько жестче, чем у PS/2 (KFKEA4XT). (PS/2 продается в черно-фиолетовой упаковке, а USB — в синей). Я даже купил себе одну PS/2 про запас, а то вдруг пропадут :)
  • Как вы пишете условия в СИ-подобных языках? Со скобками в условиях или без?
    +3
    ИМХО, само условие как таковое, не должно зависеть от восприятия. Оно должно быть однозначным для любого читателя. Главное это разделение скобками условий на группы. Что-то на подобии как большая буква идет в начале предложения и точка в конце. Так и скобки должны отделять начало и конец некоторого условия. Тогда все неоднозначности уходят сами собой.
  • Debian Lenny 5 «закончился». Переходим на Debian Squeeze 6!
    +5
    По-моему 6-й Дебиан всю жизнь назывался Squeeze.
  • «Базарный день»
    +5
    Я конечно слышал про «не знаешь что ставить ставь тире», но это просто нечто…

    Боливар — не вывезет двоих, а раз так, кто-то — должен этот мир покинуть.

    Особенно если смотреть вместе с предыдущем предложением.
  • Использование bat файлов для развертывания приложений
    0
    Оно конечно так, вот только там кое-где еще Windows 2000 использовался :)
    В общем давно дело было :)
  • Использование bat файлов для развертывания приложений
    +1
    Тоже сталкивался с похожей задачей.
    Вот только при этом использовал несколько ini-файлов для хранения настроек для каждого из вариантов и универсальный bat-файл.
    Для чтения настроек из ini-файлов использовал for:
    REM Import local constants
    for /F «eol=[ eol=; tokens=1,2* delims==» %%x in (%CONFIG_FILE%) DO SET %%x=%%y
  • Генерация псевдослучайных чисел
    0
    Я почему-то думал, что аппаратные ГСЧ практически не применяются на обычных ПК.
    А по поводу счетчика тактов, я немного не так выразился. Используется не сам счетчик как таковой, а счетчик как величина для измерения интервалов между событиями в ядре.
  • Генерация псевдослучайных чисел
    –2
    Где они такое пишут? Можно ссылочку?
    Вообще-то в основе работы /dev/random используется счетчик тактов как источник энтропии.
  • Вычисления с фиксированной точкой. Основные принципы (ч.1)
    +1
    Согласен, просто для меня экспонента — это конкретная функция с показаелем e=2.718… :)