Про Нью-Йорк ничего не скажу, а на Мосбирже это скорее всего не возможно на практике. Во первых по ссылке посмотрите на время торгов. Во вторых наличие режима не означает наличие ликвидности там. Скорее всего там пустые стаканы. А в третьих нужно узнать можно ли частнику получить туда доступ, по умолчанию дают доступ к основным торгам.

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

Вы правы. Я просто запомнил что это какая то незначительная сумма.

А может кто нибудь сказать за что минусы? Очень любопытно.

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

У меня яхтенный комментарий. Честно говоря от прочтения статьи душа в пятки ушла от страха, потому что в худшем случае не убыток, а смерть. А при таком бардаке…

Вы действительно шли трансатлантику без связи? У вас не было спутнкового телефона? А прогнозы получали как то? EPIRB то хотя бы был?

Вы в океане снимали паруса и шли под двигателем? А сколько дуло и сколько миль шли?

А когда был броченг сколько дуло когда нормально шли и сколько задуло?
Это же был кетч или йол?

Вы пили воду из яхтеных танков, откуда вода поступает в краны?

Что касается не яхтенной части, мне кажется что статья очень сильно перетянута на сторону менеджмента и опущена инжинерная сторона.
Это хорошо видно на примере с водой. Для ИТ можно привести аналог что мы делаем систему и не учли что она будет использоваться 1000+ юзеров в один момент. Пока мы не сделаем проектирование(а опытный проектировщик скорее всего не допустит такой глупой ошибки, как готовность к многопоточности) мы вообще не видим этот риск.
Я к тому, что без процедуры оценки рисков но с грамотным проектированием вернее не попасть в попу, чем без проектирования но с оценкой рисков.
Понятно что в идеале должно быть и то и то, как например в ATAM(мы кстати один раз проводили).

Для воды аналогично — думаю для опытного капитана это вообще не вопрос что делать с водой. Мене опытным нужно попроектировать(прогнать в уме все плаванье) и только потом! выявлять риски.

А скажите пожалуйста, что означает фраза «Azure SQL Database теперь совместима с SQL Server на 100%.» То есть там теперь есть распределенные транзакции, можно в запросе выбирать базу аля [SomeDb].[dbo].[someTable] итд.

Верно ли что теперь любой софт у которого требования SQL Server гнать в Azure SQL Database?

Годно ли это для продакшена или только превью?

Я получаю от ORM IQuerible и скорее всего могу сделав проекцию добавить туда еще что то не сломав при этом тот же пейджинг. Но не поручусь, нужно пробовать.

Коллеги, а правда написано вот в этой статье https://www.progress.com/blogs/rest-api-industry-debate-odata-vs-graphql-vs-ords что в GraphQL нет фильтрации?

Ну то есть что то в духе
GET serviceRoot/People?$filter=FirstName eq 'Scott'
GET serviceRoot/Airports?$filter=contains(Location/Address, 'San Francisco')

Не знаю как для GraphQL, но для OData в мире дотнета за все это отвечает ORM. Кода на сервере писать вообще не нужно.

Тут на мой взгляд упущен один очень важный риск — у многих брокеров по умолчанию в договоре прописано разрешение на то чтобы брокер брал в долг мои бумаги. У БКС это явная опция, у Финам — опция по умолчанию. У ай ти инвест я с ходу не смог разобраться.

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

То что вы пишите — очень странно! Как один лишний работающий поток блокирует все IO на 4ядерной железке.

Может быть дело в другом? В первом примере у вас gpio, data0 и data1 должен сожрать сборщик мусора(и событие никогда не приедет), а во втором (с Lightning) не должен тк вы переделали на поля, вместо локальных переменных.

Может в этом дело?

Представьте что у вас самая жесткая модель памяти — любые перестановки запрещены. Как вы сделаете любую оптимизацию out-of-order если порядок чтений и записей жестко задан?

С жесткой моделью памяти вы не построите out-of-order выполнение команд.

А AMD x64 out-of-order?

Я не очень понял ваше замечание про in-order. В IA-64 модель памяти слабее чем в x86/x64, есть value speculation, что дает больше возможностей по выполнению инструкций Out-Of-Order.

Множите пояснить свою точку зрения?

Да, спасибо, я как то этот момент совершенно упустил.

Честно говоря написал так — для демагогии:) Я не выступаю за очень частые комиты.

Оракл выкидывает редо на диск раз в н секунд, при заплнении буфера на м процентов и ещё когда то. Так что может быть в момент комита реду уже давно на диске.

Интересная статейка на тему practical-sql-tuning.blogspot.ru/2008/10/bind-peeking.html
У нас 10g как раз и я сталкивался с такой ситуацией на боевом. Вероятно, для 11g я не прав.