Говоря о времени, зачастую говорят о процессе. Начало и конец - это определенные события. А "расстояние" между этими событиями - временной срез - принято измерять в секундах. И большой взрыв тут вообще ни при чем. Просто в одной из гипотез его приняли за момент (событие) отсчета этого самого времени, тем самым задав начало среза времени. Можете с таким же успехом за начало взять дату когда сперматозоид вашего отца проник в яйцеклктку вашей матери, а конечным событие выбрать, например, момент, когда ваше тело достигнет комнатной температуры. А если вы верите в перерождение, то после "смерти" вы снова станете оплодотворенной яйцеклеткой. И вот вам ваш "большой взрыв" с цикличностью, при которой вы взрываетесь, медленно остываете и снова взрываетесь. Черт возьми, да вы даже можете эти перерождения назвать "мультивселенными". Ведь именно таковыми они для вас будут.
У кольца есть и начало и конец. Они совпадают и располагаются условно на любой выбранной точке этого кольца. А то что вы его не нашли, говорит лишь о скудности вашего мышления: то, что не вписывается в картину вашего мировосприятия вами отвергается с формулировкой "глупо".
Благодаря слою совместимости, который транслирует вызовы x32 в x64. Т.е. на x32 системе 64-приложения работать не будут, обратное возможно и зависит от ОС.
Зашел, чтобы увидеть информацию о тестировании grpc, а увидел информацию о том, как тестировать приложение на основе grpc. Вроде бы слова одни и те же, но смысл существенно иной: вы не grpc тестируете, как в заголовке написано.
Ну и да, по теме, чтобы тестировать grpc нужен не постман, а нормальные тесты xUnit / nUnit и т.п.. Т.к. при тестировании через постман и ряд схожих инструмиентов полностью отсутствует повторяемость тестов (в т.ч. их сохранность) другим участником по команде. И конечно же, ide при написании нормальных тестов поможет заполнить модели grpc, которые, к слову, могут быть изрядно сложные для текстового заполнения как в постмане.
Ну смотрите, минимум один факт. Джун пишет код на 1000 строк за Nчасов, который местами некорректно, медленно (вставить нужное) работает. Синьор пишет функционально соответствующий код на 100 условных строк за N/10 часов, с которым все ок.
Вот и выходит, что джун крайне не выгоден на ближней и с редней дистанции. И куда выгоднее и дешевле нанять мастера, чем ораву джунов.
Типовые задачи - это миф. Задачи становятся типовыми только тогда, когда специалист достаточно высокого уровня организует рельсы для этой "типовости", по которым можно пустить вагоны с джунами.
Судя по вашим высказываниям, вы не особо разбираетесь в предметной части.
grpc - это фремворк, который отличается от rest фреймворков, только тем, что данные серелизуются не в текст, а в бинарное представление.
в качестве формата данных grpc использует protobuf - бинарный формат данных. grpc работает по протоколу http2/3. grpc также способен использовать любой другой формат данных, в том числе и текстовый.
rest - это архитектурный стиль, есть огромное множество фреймворков, реализующих его в том или ином виде. в качестве формата данных зачастую используют json, но возможны и иные форматы, например, xml, text, yaml а также protobuf. подавляющее число реализаций работают по протоколу http1. никакого запрета или ограничения работать по протоколу http2/3 также нет.
так вот. grpc - это лишь фреймворк удаленного вызова процедур, который за последнее время стал крайне популярен, т.к. реализует простой описательный формат и предоставляет совместимые межплатформенные реализации, в отличии, например, от wcf\soap.
Так ваша оценка сложности не являлась качественной, потому что нарушала принцип надежности: "информация является надежной, когда в ней нет существенных ошибок и искажений". Вообще сама оценка сложности состоит из множества аспектов: оценки рисков, создаваемого технического долга, сложности реализуемого бизнеспроцесса, шаблонности (схожести с ранее решенными задачами), тестируемости, сборки и доставки, желания угодить руководству по срокам и т.п. Хотите большей объективности, точности и правдивости, оценивайте по большему списку параметров отдельно и выводите общий балл.
Если использовать для оценки качественные характеристики, а не количественные, то все будет более хорошо. Например, такой характеристикой может служить отношение принятых пулреквестов к отклоненным (в результате ошибки слияния, падения тестов или код-ревью). Перевод абсолютных количественных оценок в относительные с правильным выбором основания также повысит их полезность (вопрос только что считать "правильным" основанием для нормализации оценок). Проблема грейдовой системы в оценочных функциях, в статье это отмечено. Именно эти методы и определяют эффективность и качество конкретной системы построенной по определенному подходу. В руках идиотов любой инструмент может стать разрушительным.
Есть же схема, которая по мнению некоторых одаренных управленцев, решает проблему с долгой разработкой - просто добавить больше людей. Ибо они свято верят в линейный рост эффективности труда в зависимости от числа приложенных рук к одной задаче.
Правильно ли я понимаю, если бизнеслогика где-то в гуще кода делает подтверждение транзакции, то никакого отката не произойдет (в том числе на глубине) по подверженной транзакции, и как результат состояние бд для следующих тестов будет отличаться?
Проблема нескольких инстансов бд в их синхронизации и/или агрегации данных из них. В этом плане общая бд - проще. Операции чтения вы можете кешировать в том числе на стороне инстансов сервиса. Таким образом, если операции записи в системе не превалируют над чтением, то разделяемая общая бд может быть лучшим вариантом. Тем не менее все зависит от требований к системе.
При этом узкий специалист не просто x10 по скорости, но и по качеству результата. Порой меня посещает мысль, что фуллстек - это как единорог, - слово есть, а в природе не существует. А тех кого называют этим словом не более чем лошади, к которым бутофорский рог нацеплен, и все меряются на ком этих колпачков больше)
Говоря о времени, зачастую говорят о процессе. Начало и конец - это определенные события. А "расстояние" между этими событиями - временной срез - принято измерять в секундах.
И большой взрыв тут вообще ни при чем. Просто в одной из гипотез его приняли за момент (событие) отсчета этого самого времени, тем самым задав начало среза времени.
Можете с таким же успехом за начало взять дату когда сперматозоид вашего отца проник в яйцеклктку вашей матери, а конечным событие выбрать, например, момент, когда ваше тело достигнет комнатной температуры.
А если вы верите в перерождение, то после "смерти" вы снова станете оплодотворенной яйцеклеткой. И вот вам ваш "большой взрыв" с цикличностью, при которой вы взрываетесь, медленно остываете и снова взрываетесь. Черт возьми, да вы даже можете эти перерождения назвать "мультивселенными". Ведь именно таковыми они для вас будут.
У кольца есть и начало и конец. Они совпадают и располагаются условно на любой выбранной точке этого кольца.
А то что вы его не нашли, говорит лишь о скудности вашего мышления: то, что не вписывается в картину вашего мировосприятия вами отвергается с формулировкой "глупо".
Благодаря слою совместимости, который транслирует вызовы x32 в x64. Т.е. на x32 системе 64-приложения работать не будут, обратное возможно и зависит от ОС.
https://learn.microsoft.com/en-us/dotnet/framework/64-bit-apps
Чем вам grpc не подошёл, что возникла потребность в собственном инструменте?
Зашел, чтобы увидеть информацию о тестировании grpc, а увидел информацию о том, как тестировать приложение на основе grpc. Вроде бы слова одни и те же, но смысл существенно иной: вы не grpc тестируете, как в заголовке написано.
Ну и да, по теме, чтобы тестировать grpc нужен не постман, а нормальные тесты xUnit / nUnit и т.п.. Т.к. при тестировании через постман и ряд схожих инструмиентов полностью отсутствует повторяемость тестов (в т.ч. их сохранность) другим участником по команде.
И конечно же, ide при написании нормальных тестов поможет заполнить модели grpc, которые, к слову, могут быть изрядно сложные для текстового заполнения как в постмане.
Ну смотрите, минимум один факт.
Джун пишет код на 1000 строк за Nчасов, который местами некорректно, медленно (вставить нужное) работает. Синьор пишет функционально соответствующий код на 100 условных строк за N/10 часов, с которым все ок.
Вот и выходит, что джун крайне не выгоден на ближней и с редней дистанции. И куда выгоднее и дешевле нанять мастера, чем ораву джунов.
Типовые задачи - это миф. Задачи становятся типовыми только тогда, когда специалист достаточно высокого уровня организует рельсы для этой "типовости", по которым можно пустить вагоны с джунами.
Ну вы видимо пишете код на HTTP.
Судя по вашим высказываниям, вы не особо разбираетесь в предметной части.
grpc - это фремворк, который отличается от rest фреймворков, только тем, что данные серелизуются не в текст, а в бинарное представление.
в качестве формата данных grpc использует protobuf - бинарный формат данных. grpc работает по протоколу http2/3.
grpc также способен использовать любой другой формат данных, в том числе и текстовый.
rest - это архитектурный стиль, есть огромное множество фреймворков, реализующих его в том или ином виде. в качестве формата данных зачастую используют json, но возможны и иные форматы, например, xml, text, yaml а также protobuf.
подавляющее число реализаций работают по протоколу http1. никакого запрета или ограничения работать по протоколу http2/3 также нет.
так вот. grpc - это лишь фреймворк удаленного вызова процедур, который за последнее время стал крайне популярен, т.к. реализует простой описательный формат и предоставляет совместимые межплатформенные реализации, в отличии, например, от wcf\soap.
Должен ли я бросить исключение, если в функцию по какой-либо причине поступили некорректные параметры и выполнение ее невозможно?
В бд в свою очередь есть схемы, которые можно использовать для организации этих самых папок по той или иной логике.
Если из заголовка статьи убрать слово IT, то изменится практически ничего.
С наилучшими IT-пожеланиями, искренне ваш IT-специалист
Так ваша оценка сложности не являлась качественной, потому что нарушала принцип надежности: "информация является надежной, когда в ней нет существенных ошибок и искажений".
Вообще сама оценка сложности состоит из множества аспектов: оценки рисков, создаваемого технического долга, сложности реализуемого бизнеспроцесса, шаблонности (схожести с ранее решенными задачами), тестируемости, сборки и доставки, желания угодить руководству по срокам и т.п.
Хотите большей объективности, точности и правдивости, оценивайте по большему списку параметров отдельно и выводите общий балл.
Если использовать для оценки качественные характеристики, а не количественные, то все будет более хорошо.
Например, такой характеристикой может служить отношение принятых пулреквестов к отклоненным (в результате ошибки слияния, падения тестов или код-ревью).
Перевод абсолютных количественных оценок в относительные с правильным выбором основания также повысит их полезность (вопрос только что считать "правильным" основанием для нормализации оценок).
Проблема грейдовой системы в оценочных функциях, в статье это отмечено. Именно эти методы и определяют эффективность и качество конкретной системы построенной по определенному подходу. В руках идиотов любой инструмент может стать разрушительным.
Чтобы достать минералку в пустыне - нужно приложить больше усилий. Усилия - это труд. Нет что ли?
Есть же схема, которая по мнению некоторых одаренных управленцев, решает проблему с долгой разработкой - просто добавить больше людей. Ибо они свято верят в линейный рост эффективности труда в зависимости от числа приложенных рук к одной задаче.
Если мне не изменяет память, то откат распределенных транзакций в mssql также невозможен.
Например, сюда попадают прилинкованные бд (через odbc как вариант)
Правильно ли я понимаю, если бизнеслогика где-то в гуще кода делает подтверждение транзакции, то никакого отката не произойдет (в том числе на глубине) по подверженной транзакции, и как результат состояние бд для следующих тестов будет отличаться?
Проблема нескольких инстансов бд в их синхронизации и/или агрегации данных из них. В этом плане общая бд - проще. Операции чтения вы можете кешировать в том числе на стороне инстансов сервиса. Таким образом, если операции записи в системе не превалируют над чтением, то разделяемая общая бд может быть лучшим вариантом. Тем не менее все зависит от требований к системе.
Да нее, такое только передОвать можно)
У самого на проекте такая жуть. Когда открываешь на правку, то хочется забиться в угол и заплакать как маленькая девочка.
При этом узкий специалист не просто x10 по скорости, но и по качеству результата.
Порой меня посещает мысль, что фуллстек - это как единорог, - слово есть, а в природе не существует. А тех кого называют этим словом не более чем лошади, к которым бутофорский рог нацеплен, и все меряются на ком этих колпачков больше)