Вполне можно обойтись и без TDD

Поэтому BDD полностью может заменить TDD

Вполне можно обойтись и без TDD

Можно вообще без тестирования обойтись :)

Можно вообще без тестирования обойтись :)

Многие отказываются уже от TDD, так как в нем нет смысла))

а проверить свой код можно спокойно и с помощью BDD)

Многие отказываются уже от TDD, так как в нем нет смысла))

Но ведь бест практисис

далеко не все из этого используют))

Есть типа идеал, а есть реальность?

+ ещё два дня

типа того

но вообще было интересно на чем лучше докер развернуть

так нихрена и не понял на чем, если честно - я не гуру линукса :(

как понять на чем?

как понять на чем?

на какой из ос

на какой из ос

в смысле внутри контейнера какая ос будет крутиться?

нет, в смысле на какой ос он будет крутиться

а почему это важно? он на любой ос заводится, даже на винде

У меня кейс - развернуть на виртуальной машине. Например PhotonOS обещает полную перезагрузку сервера примерно за 5 секунд на VMWare и минимальное потребление ресурсов

RancherOS вроде как вообще все пытается в докер запихнуть

хз что за кейсы, всегда брал убунту/дебиан

Ubuntu Core тоже хотел посмотреть, но времени не хватило

хз что за кейсы, всегда брал убунту/дебиан

оптимизация производительности

а как ос влияет на производительность докер-контейнеров?

у TDD были проблемы с тем, что тестов становилось слишком много и люди просто не успевали писать код

BDD - это тоже самое, но только надо понимать какие тесты реально нужны

мы перестаем пытаться покрыть тестами все и покрываем только гринвей, проверям что система работает

то или после - кому как удобнее

примерно так

Виртуализация сама по себе так или иначе снижает производительность. В каких то случаях это заметно сильнее, в каких то - меньше.

То есть, условно, в одном случае у тебя съестся 100МГц на нужды виртуализации, а в другом - 400.

это понятно, но я не понимаю, как на это ос влияет

оптимизация под конкретную задачу. Отключение (и вообще выпиливание) лишних процессов. Тут можно привести в пример 1С, которая заметно просаживается в производительности, если на сервере не отключить все лишние процессы.

когда это ос становилась узким местом? ?

оптимизация ради оптимизации - плохая практика

когда это ос становилась узким местом? ?

Чаще, чем ты можешь себе представить

По крайней мере для облачных решений

Чаще, чем ты можешь себе представить

ну это прям совсем надо хилые машинки брать

Ребята есть какая годная видео визитка ?

Скиньте ссылку

Тебе же никто не выделяет гарантированные ресурсы. Ты купишь 3.5 ГГц, а тебе гарантируют только 10%, а остальное по переподписке

руби сам по себе не про ограниченные ресурсы

Можно, конечно купить гарантированно, но это много дороже

собственно вся бизнес модель облачных провайдеров на том и построена, что ты продаешь больше, чем у тебя есть

облачные провайдеры тебе обычно дают на выбор убунту/дебиан

центос

Тебя ничто не останавливает что то свое поставить

обычно там темплейты просто загружены на самые популярные ОС

а зачем так себе жизнь усложнять? какие ты ждешь нагрузки, чтобы тебе не хватило каких-нибудь 2 ядра/4 гига с убунтой?

Я вообще никаких не жду. Но не называя имен скажу, что есть клиенты, которые любят купить самую дешевую машину и захреначить использование CPU и SSD на полную, а потом жаловаться на то, что низкая производительности и тыкать в договор.

Я вообще никаких не жду. Но не называя имен скажу, что есть клиенты, которые любят купить самую дешевую машину и захреначить использование CPU и SSD на полную, а потом жаловаться на то, что низкая производительности и тыкать в договор.

ну тут тебе никакая ос не поможет :)

Поэтому мы как провайдер сейчас прорабатываем решения по вариантам оптимизации для таких клиентов.

ну тут тебе никакая ос не поможет :)

К сожалению, да

Но и послать без оснований тоже нельзя

99% серверов - это убунту, центос, дебиан, вряд ли какой-то админ захочет возиться с каким-то неизвестным дистрибутивом

собственно на них и докер без проблем ставится

в докер контйнеры обычно ставят alpine linux

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

Плюсану за центос

Работает шикарно, с учётом того что гоняю докер в докере

центос хорош, но, зараза с обновлением пакетов запааааздывает относительно тех же бубунту

Game.new.start_game

если это метод экземпляра класса

если это статический метод, то Game.start_game

ты же книгу читал, должен знать) Или задания не делал? ?

не читал книгу

ERROR: S client not available

у меня её не сохраняло

а.. ну читай тогда, и задания делай

см.в привате

надо сделать объект класса

повторить: что такое класс, что такое экземпляр класса (объект)

ну и что такое статические методы

из конструктора, кстати, желательно не вызывать методы, не должно быть никакого поведения в конструкторе

also: https://www.yegor256.com/2015/05/07/ctors-must-be-code-free.html

ну и для целей тестирования удобно

кто-то может подсказать как работает данная конструкция..интуитивно есть понимание, но чот я в нем не уверен

def +(other) BookInStock.new("#{@title}, #{other.title}", "#{@author} and #{other.author}", @price + other.price) end

def +(other) BookInStock.new("#{@title}, #{other.title}", "#{@author} and #{other.author}", @price + other.price) end

Инициализируется объект типа BookingStore

ну и возвращается в качестве результата операции +

def +(other) BookInStock.new("#{@title}, #{other.title}", "#{@author} and #{other.author}", @price + other.price) end

У тебя это отдельный метод или класс тоже есть ? К примеру, откуда инстанс переменная @title и @price тянется ? А так это создание в памяти объетка BookinStock, но не в базе.

У тебя это отдельный метод или класс тоже есть ? К примеру, откуда инстанс переменная @title и @price тянется ? А так это создание в памяти объетка BookinStock, но не в базе.

@title и @price очевидно инстанс переменные

и очевидно они созданы при инициализации объекта

class BookInStock attr_accessor :title attr_writer :author attr_reader :price def initialize(title, author, price) @title, @author, @price = title, author, price end def price_in_cents Integer(@price * 100 +0.5) end def price_in_cents=(value) @price = value / 100.0 end def +(other) BookInStock.new("#{@title}, #{other.title}", "#{@author} and #{other.author}", @price + other.price) end end

@title и @price очевидно инстанс переменные

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

это весь класс

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

а почему "ни к чему"-то?

а почему "ни к чему"-то?

Не совсем понял сообщение

Не совсем понял сообщение

ну ты очень много сразу предположил. Что переменные инстанса взялись ниоткуда

хотя ничто на это не указвает

ну ты очень много сразу предположил. Что переменные инстанса взялись ниоткуда

Так я не говорил что косячно написано, я просто уточнил. Не совсем понимаю, в чем проблема ?

название метода странное)

нужно назвать понятно, например add_book()

нужно назвать понятно, например add_book()

куда add?

def +(other) назови нормально. сначала.

def +(other) назови нормально. сначала.

не хочу тебя расстраивать, но подобный метод даже в вики называется def+(another)

кстати если кому интересно тут норм объясняют

https://ru.wikibooks.org/wiki/Ruby/%D0%9F%D0%BE%D0%B4%D1%80%D0%BE%D0%B1%D0%BD%D0%B5%D0%B5_%D0%BE_%D0%BC%D0%B5%D1%82%D0%BE%D0%B4%D0%B0%D1%85