> и прочих технических требований к нагруженным системам
Обычно на начальном этапе _технических_ требований почти никаких, и надо чтобы оно просто работало и не создавало геморрой.
> Только не лезьте, пожалуйста в вопросы в которых вы не компетентны.
Хехе, забавный вывод, оставлю без комментариев.
> разработка mvp затягивается на какие — то неадекватные сроки
> выбор компонентов исходя из производительности, а не удобства
а теперь вы мне доказываете что на этапе mvp надо выбирать исходя из производительности? где логика? и где логика в том, что вы критикуете выбор NATS как выбор исходя из производительности, при том, что автор указал, что и по удобству ему NATS кажется более предпочтительным
> считаете допустимо для «высоконагруженных» ситстем
Возможно я излишне вольно трактую посыл автора статьи, но мне кажется нормальным выбрать достаточно универсальное мейнстримное решение на этапе, когда специфика проекта еще не выявлена. Я трактую примерно в духе «взять что-то, что в среднесрочной перспективе не доставит геморроя, при этом не тратя на это много времени». Честно не понимаю, где тут люди видят сложность и перенавороченность предлагаемого набора.
> lxc != docker
Я это прекрасно понимаю.
> И вы что, автор чтобы что-то там подразумевать?
Подразумевал при прочтении. Если автор имеет в виду именно голый LXC — соглашусь, зря он так.
> выбор компонентов исходя из производительности, а не удобства
> Да и кластеризуется он быстрее и легче чем RabbitMQ.
Ээээ
Скорее соглашусь, но и здесь описаны детали и в аналогии со строительством есть «типовые» для материалов подходы и архитектуры: кирпичный дом vs панельный vs современный мейнстрим (железобетонный каркас + кирпичные стены): материалы определяют архитектуру и походы.
При том, что я сильно на стороне бизнеса (в противоположной от архитектурных стронафтов), не увидел в статье явного overengineering. Нормальная архитектура, не сильно сложнее ХХИВП, но заметно стабильнее.
Я не настоящий сварщик, и все описанное — лишь гипотезы. Но, кажется, между «будет магниться к желобу со страшной силой» и «не будет магнититься» есть куча градаций, которые могут сработать.
Если принимать как данное, что в «С» все идеально, то незачем создавать что-то новое. Вопрос «принимать или не принимать» оставим за скобкой.
Еще, если мы принимаем, что неявные преобразования — «иногда и не совсем зло, а скорее добро» :), то так недолго и до перемножения числа и строки дойти (чур меня)…
А вы какой вариант вычисления хотите сделать автоматическим/неявным в таком, например, случае?
let priceTotal:Int = (Int) (price * quantity)
или
let priceTotal:Int = ((Int) price) * quantity
да, в данном случае все просто. Но возможны варианты. И лучше всего, чтоб все было однозначно.
Обычно на начальном этапе _технических_ требований почти никаких, и надо чтобы оно просто работало и не создавало геморрой.
> Только не лезьте, пожалуйста в вопросы в которых вы не компетентны.
Хехе, забавный вывод, оставлю без комментариев.
> разработка mvp затягивается на какие — то неадекватные сроки
> выбор компонентов исходя из производительности, а не удобства
а теперь вы мне доказываете что на этапе mvp надо выбирать исходя из производительности? где логика? и где логика в том, что вы критикуете выбор NATS как выбор исходя из производительности, при том, что автор указал, что и по удобству ему NATS кажется более предпочтительным
Я?
> считаете допустимо для «высоконагруженных» ситстем
Возможно я излишне вольно трактую посыл автора статьи, но мне кажется нормальным выбрать достаточно универсальное мейнстримное решение на этапе, когда специфика проекта еще не выявлена. Я трактую примерно в духе «взять что-то, что в среднесрочной перспективе не доставит геморроя, при этом не тратя на это много времени». Честно не понимаю, где тут люди видят сложность и перенавороченность предлагаемого набора.
> lxc != docker
Я это прекрасно понимаю.
> И вы что, автор чтобы что-то там подразумевать?
Подразумевал при прочтении. Если автор имеет в виду именно голый LXC — соглашусь, зря он так.
> выбор компонентов исходя из производительности, а не удобства
> Да и кластеризуется он быстрее и легче чем RabbitMQ.
Ээээ
это что, сложно?
> lxc вместо докера
честно говоря, я под lxc подразумевал докер. если нет — зря
> выбор компонентов исходя из производительности, а не удобства
где?
> решение несуществующих проблем, введение технологий по принципу «чтобы было»
детали плз
Делали с помощью общей для всех вкладок куки. Т.к. синхронизации никакой нет, пришлось делать координацию через выбор лидера.
Хорошо что больше нет необходимости так извращаться :)
webOS 1.х в плане производительности казался несбыточной мечтой…
Еще, если мы принимаем, что неявные преобразования — «иногда и не совсем зло, а скорее добро» :), то так недолго и до перемножения числа и строки дойти (чур меня)…
let priceTotal:Int = (Int) (price * quantity)
или
let priceTotal:Int = ((Int) price) * quantity
да, в данном случае все просто. Но возможны варианты. И лучше всего, чтоб все было однозначно.