Мизулина предлагает оградить российских детей от пагубного влияния онлайн видеоигр

Простите за придирку, но вы, наверное, имели ввиду люмпенов, а не маргиналов?

Сэнди Метц и объектно-ориентированное проектирование в Ruby

Насчёт хэша в качестве аргумента конкретно в данном случае, чем хуже это?

class Person
  attr_accessor :name, :height, :hair_color

  def initialize(name: nil, height: 0, hair_color: nil)
    @name = name
    @height = height
    @hair_color = hair_color
  end
end

Person.new(name: "Travis", hair_color: "brown", height: 6.25)

Манипуляции сознанием, как правильно читать новости и кто кому не продал Model-X

Тем не менее, это будет непрофессионально.

PHP-Дайджест № 78 – интересные новости, материалы и инструменты (18 – 31 января 2016)

Добавлю ещё.

Мне как разработчику на Laravel не обязательны версии каждые 6 месяцев. Мне, как потребителю, нужны стабильные релизы, а выходят они по расписанию или с задержками — не важно. Свои дедлайны разработчики фреймворка могут хранить при себе.

Подобное расписание привлекает неофитов, которые выбирают фреймворк и видят, что новая версия вышла 3-4 месяца назад, после чего бегут туда.

2 версии в 1 год — это исключительно маркетинг для привлечения большего количества разработчиков — не более.

PHP-Дайджест № 78 – интересные новости, материалы и инструменты (18 – 31 января 2016)

Проекты типа такого должны выпускаться тогда, когда они готовы выпускаться, а не по графику — не пирожки всё таки пекут и не пятилетки за 4 года делают.

И та же убунта это отлично показала своими глючащими раскладками и прочими артефактами. Так показала, что все, кто не ищут приключений, пользуются исключительно LTS-версиями. Некоторые даже не сразу, а после первого патча.

Анархию и хаос скорее вызовет факт что к концу этого месяца должны 100% выкатить релиз.

PHP-Дайджест № 78 – интересные новости, материалы и инструменты (18 – 31 января 2016)

Что-то laravel со своим расписанием релизов и LTS-версиями стал похож на ubuntu. Нехорошо это.

Давить или не давить? Формируем этику беспилотного автомобиля при помощи опросов

А как же вы в общественный транспорт садитесь? Водитель точно также может решить, что его и ваша жизнь не так важны.

Давить или не давить? Формируем этику беспилотного автомобиля при помощи опросов

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

Грипп: врачи советуют «Тамифлю». Но, доказательна ли доказательная медицина?

Где-то читал, что не на один штамм можно получить иммунитет, но и на схожие.

Проблема дублирования и устаревания знания в mock-объектах или Интеграционные тесты — это хорошо

А вам самому не кажется странным, что тест то модульный, то сразу интеграционный и это постоянно меняется, причём при изменении не теста, а реализации?

И я уже задавал вопрос — почему при использовании стандартных классов он остаётся модульным, а при нестандартных перестаёт таковым быть? Разве модульность/интеграционность определяется набором библиотек?
И какое определение модульного теста говорит, что в внутри него не должно быть зависимостей? Или получается, что могут быть, но только некоторые?
Определение модульного теста определяет тестирование изолированного модуля, юнита, некой абстракции с которой мы работаем как с чёрным ящиком — не более.

Разница между модульными и юнит-тестами возможна только в рамках одного проекта, где используются и те, и другие, когда мы выделяем модули, тестируем их модульными тестами, а затем проверяем совместную работу интеграционными.
Написав 1 тест без моков и прочего вы не напишете интеграционный тест, вы напишите модульный тест, просто рассматривать тестируемый объект будете как один большой модуль, чёрный ящик, просто напросто большую абстракцию.

P.S. сомневаюсь что существуют миллиарды людей, которые используют определения модульного/интеграционного тестирования.

Проблема дублирования и устаревания знания в mock-объектах или Интеграционные тесты — это хорошо

Вот ситуация.

Я тестирую какой-то объект. Внутри него используется ещё 1.
Он прямо там и создаётся, больше нигде не используется. Я его решил не тестировать, потому что он, к примеру, слишком прост, считает мне 2 + 2. Я не хочу его передавать через IoC или как-то ещё. Я даже имею возможность его замочить его без IoC, но не хочу этого делать. Судя по-Вашему, это интеграционный тест.

Но стоит мне только перенести весь функционал из этого вспомогательного объекта в основной, так тест становится модульным?

Ну это же глупость!

Проблема дублирования и устаревания знания в mock-объектах или Интеграционные тесты — это хорошо

Допустим, а как быть, если язык позволяет патчить стандартные библиотеки напрямую и мы используем данную стандартную, но пропатченную библиотеку?

Проблема дублирования и устаревания знания в mock-объектах или Интеграционные тесты — это хорошо

А если я вместо стандартной библиотеки времени использую нестандартную, то уже не модульное?

Зачем вы цепляетесь к словам «всё в целом»? Конечно же имелось ввиду как должен «весь в целом» работать функционал.

Проблема дублирования и устаревания знания в mock-объектах или Интеграционные тесты — это хорошо

При TDD разработка мне видится так:
1. при необходимости внесения изменений человек описывает парочку интеграционных тестов, если это возможно, которые показывают как всё должно работать в целом.
2. начинает вносить изменения, если в итоге изменения небольшие и покрываются тем что он написал, то всё хорошо.
3. если человек начинает терять контроль над кодом в плане тестов (например, внутри объекта идёт сложная агрегация из ещё чего-то), то человек тестирует и эти модули.

Конечно же, это «идеальный вариант» на практике часто пишутся сначала «кусочки» все или не все, которые потом объединяются во что-то большее. Но сама идеология TDD, по-моему, подразумевает разработку от общего к частному, а не наоборот. Но, возможно, это уже BDD.

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

Проблема дублирования и устаревания знания в mock-объектах или Интеграционные тесты — это хорошо

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

В российских школах могут запретить устройства с возможностью выхода в Сеть

Зачем же сразу впадать в крайности?

В российских школах могут запретить устройства с возможностью выхода в Сеть

Никогда не видел, чтобы «нелюбимчик» учителя был затравлен классом, скорее наоборот.

Чего мы больше получаем от компьютерных игр: вреда или пользы?

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

Чего мы больше получаем от компьютерных игр: вреда или пользы?

В комментарии было сравнение видео игр и пустых разговоров с друзьями. Для упрощения предполагалось, что компьютерные игры исключают или имеют минимум общения, иначе такое сравнение было бы бессмысленно.

Прошу учитывать контекст а не выдёргивать фразы и заниматься софистикой.

Чего мы больше получаем от компьютерных игр: вреда или пользы?

В случае разговора с друзьями мы укрепляем социальные связи из-за чего получаем выгоду, пользу.