All streams
Search
Write a publication
Pull to refresh
26
0

User

Send message
Я бы больше ориентировался на публичную отчётность, а не на динамику цен на бирже.
Не понял про налаженную логистику. О чем вы говорите? Сбербанк массово никуда ничего не доставляет, о какой логистике вы говорите?

А наличные деньги в банкоматах и отделениях Сбербанка, по вашему, с помощью телепорта появляются? То же самое относится к пластиковым картам, которые изготавливаются не в том месте, где вы их получаете.

Так же, у Сбербанка есть сервис «Моя доставка» (описывается как «комплексное логистическое обслуживание вашего бизнеса»), который «предоставляет максимальную географию доставки по России», потому что «компания имеет собственную курьерскую службу, склады, точки выдачи».
Брокеры и трейдеры с Уолл-стрит на протяжение многих лет высказывали недовольство высокими комиссиями, которые приходилось платить крупнейшим американским биржам. Теперь компании Morgan Stanley, Fidelity Investments и Citadel Securities LLC решили изменить сложившуюся ситуацию.

Я, может, неправ, но у меня постоянно складывается впечатление, что это не у бирж высокие комиссии, а у брокеров. Для примера (не буду называть ни брокера, ни биржу, но брокер — точно не ITI Capital), со сделки на полторы тысячи рублей брокер берёт два с половиной рубля, а биржа — 14 копеек.
Сами комментарии — это не способ монетизации. Это средство привлечения внимания к своему профилю. А чем больше просмотров профиля, тем больше потенциальных подписчиков, с помощью которых уже и проходит монетизация за счёт показа рекламы.

Кстати, про лайки под комментариями на YouTube: когда много лайков, ваш комментарий выносится вверх. Получается, реклама вашего профиля постоянно висит прямо под видео, и вы за эту рекламу никому ничего не платите.
в выписке три дня будет висеть HOLD

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

Уточните, что именно мне кажется? Я выражение «мне кажется» использовал в другом абзаце, и там речь шла уже не о выписке.
Согласен, и то и то — деньги, но когда используется слово «реальное», это может относиться только к наличным.

3. я говорил что движение денег в международных платёжных системах идёт только на третий день.

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

Мне кажется, некорректно сравнивать одну вещь с позиции пользователя, а другую — с позиции внутреннего устройства. Биткоин для конечного пользователя работает медленнее, чем банк. Чтобы доказать обратное, нужно подменять понятия.
Ну, наличные двигаются реально, а деньги на счетах — виртуально. Вы просто именно на реальное движение денег внимание обращали.

В остальном, мне кажется, некорректно сравнивать ощущения конечного пользователя от биткоина и ощущения банка от использования традиционных денег, потому что в случае с банком у конечного пользователя есть ощущение, что всё проходит в течение нескольких секунд.
Я не совсем понимаю, что вы критикуете. Грубо говоря, я писал, что сравнивать семена помидоров с только что съеденым помидором — это не совсем корректно, а вы пишете, что помидоры одного сорта лучше помидоров другого сорта — это не то, о чём я писал.
Now the fun part, for starters just prove that

thing->Energy = thing->Mass() * np.math.pow(lib.constants.speedOfLightInVacuum, 2)

is a better practice than this:

E = m * c^2

I think, one-letter variable names are good when you write one-line programs, a.k.a formulas. Usually, formulas are accompanied with a sheet of text explaining meaning of all things inside the formula.

So, if you want write something like this

$E = $m * $c ** 2


Then you need to write some documentation explaining meaning of $E, $m, and $c. But you don't need to write such documentation when you write something like this

$energy = $mass * $lightSpeed ** 2


thing->Energy = thing->Mass() * np.math.pow(lib.constants.speedOfLightInVacuum, 2)

is a better practice than this:

E = m * c^2

Did you mean, that this is a better alternative?

thing->E = thing->m() * np.math.pow(lib.constants.c, 2)

I mean, you're comparing non-programming notation with an example of code. And the code example uses different language constructs which are specific to the language and which are not learned in school by everybody.
Реальное движение денег — это когда двигаются наличные, потому что у наличных максимальная ликвидность. В реальности, из-за механизма взаиморасчётов, деньги могут вообще не двигаться, но взаиморасчёты будут проходить нормально, и будет казаться, что деньги двигаются.

Просто вы сравниваете движение денег в Системе с движением биткоинов без Системы. Если двигать биткоины с использованием такой же системы, которая используется для движения наличных, то разницы вообще не будет видно.

Я это к тому, что «несколько дней», о которых вы говорили, — это всё ещё не реальное движение денег.
Do you know any other useful ways to do it without speaking?

I agree, while you're writing/speaking, you're improving your English. Practice makes perfect.
[offtop]
Some time ago I saw a tendency, people translate English articles to Russian. Now people translate Russian articles to English. It looks promising.
[/offtop]

Компания

Это сколько же нетерпимости нужно иметь, чтобы не признавать русским слово, которое используется в языке почти 400 лет.
Я отдаю код 204. В этом случае, вместе с хэдерами, размер ответа от Nginx получается где-то 100 байт. И до этого момента я не встречался с ситуацией, чтобы браузер делал несколько запросов на такой ответ.

location @204 {
    keepalive_timeout 0;
    return 204;
}
У меня некоторое время довольно-таки хорошо работала такая конструкция (пишу без предварительного тестирования — по памяти, так что код может быть нерабочий, но, главное, из него будет понятен смысл):

class MyRows extends React.Component {
    constructor(props) {
        super(props);

        this.state = {
            rows: props.rows,
        };
    }

    /**
     * @param {SyntheticEvent} event
     */
    handleDelete = event => {
        let rows = Object.assign({}, this.state.rows);

        delete rows[event.target.dataset.rowId];

        this.setState({rows});
    }

    render() {
        return <div>
            {Object.values(this.state.rows).map(row => {
                return <button
                    key={row.id}
                    onClick={this.handleDelete}
                    data-row-id={row.id}
                >Delete row #{row.id}</button>;
            })}
        </div>;
    }
}


Суть в том, что я пишу параметры в нативный для DOM dataset конкретной кнопки, и потом в хэндлере обращаюсь к этому дата-сету за данными. При таком подходе не приходится делать бинд каждый раз, когда происходит ре-рендер.
Удобно в качестве конспекта — да. Но это удобство в ущерб стабильности. Грубо говоря, разработчику будет удобно разрабатывать код 10 человеко-часов, но 10 000 000 человеко-часов код будет работать нестабильно на production-сервере.
p.s. вместе с flow, propTypes становятся еще более удобными в режиме разработки и поддержки.

В режиме поддержки PropTypes не становятся более удобными, потому что поддержка обычно осуществляется для пользователей, а пользователи — это те, кто использует production-версию, и в режиме поддержки приходится обычно работать с кодом и логами оттуда, где PropTypes не работают.
Отсутствуют или недостаточно подробно описаны Prop Types.

Я всегда считал, что PropTypes — это фишка только для development-версии. Когда это ещё было встроенным функционалом React.js, это игнорировалось в продакшене, потому что даёт снижение производительности приложения, (Насколько я понимаю, отдельный пакет prop-types, который появился после версии 15.5, тоже работает только в режиме development.)

По сути, PropTypes отрабатывает только в режиме разработки. Это значит, что если в продакшене для какого-то свойства был передан неподходящий параметр, продакшн от этого не будет защищён, потому что вся ответственность за типы была передана в PropTypes, который в продакшене игнорируется. Когда навязывается использование PropTypes, у разработчиков складывается ложное впечатление, что они предусмотрели больше, чем это есть на самом деле, что ведёт к снижению качества продукта.

По сути, нет смысла тратить время на PropTypes. Лучше его потратить на то, чтобы компонент самостоятельно мог выдавать ошибки или мог принудительно генерировать дефолтные значения для props, если ничего не было передано (или конвертировать входные значения в подходщий формат, если они имеют неправильный). Чтобы PropTypes мог это делать, нужно либо использовать в продакшене development-версию React, либо модифицировать его, чтобы PropTypes мог работать в продакшене.

Основная моя критика в этом:

  • В режиме production PropTypes не защищает от неправильных входных данных;
  • В режиме production PropTypes нарушает ещё один ваш критерий оценки: «Не удален „старый код“, то есть такой код, который нигде не используется»
Ясно, спасибо. Я думал, что какие-то новые новые события произошли, которые резко подорвали доверие к любым новостям вообще во всём мире. Просто фраза очень драматично выглядела. Похоже, я, всё-таки, ничего не пропустил.

Information

Rating
Does not participate
Location
Россия
Registered
Activity