Однако свойство радиоактивного распада таково, что он может происходить без каких-то причин.
Утверждение, на котором основан целый пласт заключений.
Что, если при рождении частицы, она приобретает в своей структуре нечто, величина чего как-то связана с итоговым временем жизни частицы. Мы не все знаем о том, что происходит внутри частицы в момент ее зарождения, и отрицать такой вариант не можем. Отсюда, можно предположить, что причина распада - истечение "таймера", присвоенного при рождении частицы. А причина присвоения такого "таймера" - факт рождения частицы и особенность процесса, согласно предположению.
Докажите, что распад действительно может происходить без каких-то причин.
Предпочитаю в деталях знать схему данных, их взаимосвязь и пропорции объемов. Для каждого отдельного случая какого-то запроса представлять работу процессора(итератора) запроса, и подставлять ему такой flow, который понятен и более менее оптимален. Если обладать такими знаниями о собственной системе, то вручную составленный запрос дает стабильно идентичную производительность, хорошую или плохую - второстепенно, первостепенно - одинаковую стабильную, можно улучшать свои знания и оптимизировать, в итоге опять получать стабильную производительность. При росте объема данных конечно можем получить падение скорости, но это ожидаемо. А что, если ваш оптимизатор безошибочно сработал по стоимостям и заложенному алгоритму, но сделал итоговую производительность хуже, чем по изначальному запросу? Что, если стоимости динамично меняются, и план запроса в итоге меняется, и в итоге производительность "флакает"? В чем формальное доказательство, что именно написанный Вами алгоритм подбора по стоимостям дает какой-то плюс-минус оптимальный результат? Ведь пока вы его не прогоните на полном объеме данных и не сделаете замер, до этого момента все "догадки", некая стоимость Шрёдингера, простите. Не ради троллинга, правда хотелось бы узнать, как быть уверенным, что оптимизация не сломала изначально хороший запрос?
Всегда стоит задумываться о своей независимости, в той или иной форме. Наемный труд - это зависимость от компании, а там как повезет. Не у всех получается организовать дело, вместо кодинга все смещается в неприятную работу, но это и не всегда требуется. Попытаться выйти на контрактные работы по маленьким проектам - уже шаг. Баланс между кодингом и ведением бизнеса, можно попробовать с доверенным партнером, типа супруги или друга, которые могли бы взять ту самую нетехническую часть. В итоге, можно работать не над своим имиджем конкретного человека с ФИО и "возрастом", а над имиджем своей компании, за которой скрыть возраст. Мысли вслух.
Ой, какие все зануды... заканчивайте судить и оценивать предпринимателя. Займитесь тем, что умеете - предложите предпринимателю экономически эффективную автоматизацию и заработайте денег. Может быть и у бизнеса уже есть мысли как масштабировать деятельность, или хотя бы закрыть дыры в управлении, сделать проще, прозрачнее процессы на предприятии. Автор блога вам фактически подбрасывает готовую работу, полугаражные и развивающиеся малые предприятия - бизнес-евангелист.
Пример RNCE + DCE дичь. Какое-то нарушение причинно-следственных связей. RNCE оптимизация заменяет if (ptr == NULL) на if (false) из-за того, что выше есть разыменование, которое гарантирует, что либо точно ptr != NULL, либо будет исключение до конструкции if. А затем применяется DCE, который удаляет первопричину применения оптимизации RNCE. Какого? Если будет удалена первопричина применения RNCE, то она не может быть применена, а следовательно у DCE нет предпосылок применяться в таком виде.
В тексте не зря есть упоминание корпоративной лицензии. Покупаете корпоративную лицензию, оплачивая ее со счета в подходящем банке, затем подключаете к лицензии сотрудников по их email.
Кроме того, есть fallback версия на момент покупки/продления лицензии, т.е. Вы перестанете получать обновления, пока не оплатите, но можете откатиться на версию на момент прошлой покупки/продления.
Т.е. работать можно, но в общем ничего приятного последние дни не приносят никому.
Если честно, то не понял сравнения с Kafka. Как можно сравнивать синхронный (gRPC, REST, JsonRPC и прочие) и асинхронный (очереди [*MQ] и журналы [Kafka]) принципы взаимодействия? Совершенно разные подходы не просто в коде, а вообще во всей системе и логике.
И grpcui. Недостаток утилит конечно в том, что при отсутствии рефлексии в grpc сервисе, надо ручками с помощью protoc компилировать protoset файлы из proto файлов контрактов. Обычно ок, тоже можно автоматизировать.
Именованные аргументы хорошо защищают от таких ошибок неявного кастинга. Сразу было бы видно «capacity: ‘[’», и сразу бы возник вопрос.
Да и вообще, нормальный проект должен быть покрыт тестами и бенчмарками. В данном случае есть подозрение, что это какой-то отладочный ToString.
Вам нужны достаточно большие массивы актуальных данных, которые известны только GDS системам, у которых авиакомпании заводят свои тарифы. Разные авиакомпании работают с разными GDS, кто-то с российской, кто-то с зарубежными, их несколько. Чтобы иметь «все», получается, надо «ходить» по API ко всем. Это ж сколько Вы будете им платить за такое кол-во запросов к ним…
Или Вы будете «парсить» сайты авиакомпаний? У многих есть защита на кол-во запросов от одного и того же IP-адреса.
Кстати. Если Вам достаточно иметь метод с передаваемыми аргументами, то вполне достаточно аллоцировать память через Marshal.AllocHGlobal например, потом запротектить на выполнение (единственный хак вне платформы), затем в этот участок памяти перелить опкоды (тут iced либа в помощь), затем через тот же Marshal получить вполне законный управляемый делегат — Marshal.GetDelegateForFunctionPointer, который можно где-то сохранить и переиспользовать. Все законно, в рамках платформы.
Чтобы Вы не тратили время на разработку и отладку генератора нативного кода, вот Вам ссылка на проект, в котором реализованы все инструкции x86/x64, даже векторизация.
Известная дорога через Кисловодск в Джилы-Су у склона Эльбруса. Чуть дальше от поселения Кичи-Балык можно попасть в Долину нарзанов. В самом Джилы-Су даже европейских ребят можно встретить, купающихся в серебрянных источниках. Эх, какие термы можно было бы там сделать…
Вы увидели только малую часть той великолепной дороги (полностью асфальтированной, кстати) с прекрасными пейзажами, скозь высокогорные луга с коровками и овечками, иногда сквозь облака, а в конце дороги вот:
Утверждение, на котором основан целый пласт заключений.
Что, если при рождении частицы, она приобретает в своей структуре нечто, величина чего как-то связана с итоговым временем жизни частицы. Мы не все знаем о том, что происходит внутри частицы в момент ее зарождения, и отрицать такой вариант не можем. Отсюда, можно предположить, что причина распада - истечение "таймера", присвоенного при рождении частицы. А причина присвоения такого "таймера" - факт рождения частицы и особенность процесса, согласно предположению.
Докажите, что распад действительно может происходить без каких-то причин.
Предпочитаю в деталях знать схему данных, их взаимосвязь и пропорции объемов. Для каждого отдельного случая какого-то запроса представлять работу процессора(итератора) запроса, и подставлять ему такой flow, который понятен и более менее оптимален. Если обладать такими знаниями о собственной системе, то вручную составленный запрос дает стабильно идентичную производительность, хорошую или плохую - второстепенно, первостепенно - одинаковую стабильную, можно улучшать свои знания и оптимизировать, в итоге опять получать стабильную производительность. При росте объема данных конечно можем получить падение скорости, но это ожидаемо. А что, если ваш оптимизатор безошибочно сработал по стоимостям и заложенному алгоритму, но сделал итоговую производительность хуже, чем по изначальному запросу? Что, если стоимости динамично меняются, и план запроса в итоге меняется, и в итоге производительность "флакает"? В чем формальное доказательство, что именно написанный Вами алгоритм подбора по стоимостям дает какой-то плюс-минус оптимальный результат? Ведь пока вы его не прогоните на полном объеме данных и не сделаете замер, до этого момента все "догадки", некая стоимость Шрёдингера, простите. Не ради троллинга, правда хотелось бы узнать, как быть уверенным, что оптимизация не сломала изначально хороший запрос?
Всегда стоит задумываться о своей независимости, в той или иной форме. Наемный труд - это зависимость от компании, а там как повезет. Не у всех получается организовать дело, вместо кодинга все смещается в неприятную работу, но это и не всегда требуется. Попытаться выйти на контрактные работы по маленьким проектам - уже шаг. Баланс между кодингом и ведением бизнеса, можно попробовать с доверенным партнером, типа супруги или друга, которые могли бы взять ту самую нетехническую часть. В итоге, можно работать не над своим имиджем конкретного человека с ФИО и "возрастом", а над имиджем своей компании, за которой скрыть возраст. Мысли вслух.
Ой, какие все зануды... заканчивайте судить и оценивать предпринимателя. Займитесь тем, что умеете - предложите предпринимателю экономически эффективную автоматизацию и заработайте денег. Может быть и у бизнеса уже есть мысли как масштабировать деятельность, или хотя бы закрыть дыры в управлении, сделать проще, прозрачнее процессы на предприятии. Автор блога вам фактически подбрасывает готовую работу, полугаражные и развивающиеся малые предприятия - бизнес-евангелист.
А как же port knocking?
Можно поставить особый шрифт и сослаться на другую интерпретацию
Пример RNCE + DCE дичь. Какое-то нарушение причинно-следственных связей. RNCE оптимизация заменяет if (ptr == NULL) на if (false) из-за того, что выше есть разыменование, которое гарантирует, что либо точно ptr != NULL, либо будет исключение до конструкции if. А затем применяется DCE, который удаляет первопричину применения оптимизации RNCE. Какого? Если будет удалена первопричина применения RNCE, то она не может быть применена, а следовательно у DCE нет предпосылок применяться в таком виде.
В тексте не зря есть упоминание корпоративной лицензии. Покупаете корпоративную лицензию, оплачивая ее со счета в подходящем банке, затем подключаете к лицензии сотрудников по их email.
Кроме того, есть fallback версия на момент покупки/продления лицензии, т.е. Вы перестанете получать обновления, пока не оплатите, но можете откатиться на версию на момент прошлой покупки/продления.
Т.е. работать можно, но в общем ничего приятного последние дни не приносят никому.
Напомните пожалуйста, в каких годах была та самая эпоха красивого кода?
Если честно, то не понял сравнения с Kafka. Как можно сравнивать синхронный (gRPC, REST, JsonRPC и прочие) и асинхронный (очереди [*MQ] и журналы [Kafka]) принципы взаимодействия? Совершенно разные подходы не просто в коде, а вообще во всей системе и логике.
И grpcui. Недостаток утилит конечно в том, что при отсутствии рефлексии в grpc сервисе, надо ручками с помощью protoc компилировать protoset файлы из proto файлов контрактов. Обычно ок, тоже можно автоматизировать.
Если у Вас не работает linux/arm64/v8, поищите linux/arm64, по тэгам типа версия-aarch64.
Вы проводили какой-нибудь R&D? Например, есть Quartz.NET либа, которая покрывает перечисленные Вами в статье требования и предлагает даже больше.
Именованные аргументы хорошо защищают от таких ошибок неявного кастинга. Сразу было бы видно «capacity: ‘[’», и сразу бы возник вопрос.
Да и вообще, нормальный проект должен быть покрыт тестами и бенчмарками. В данном случае есть подозрение, что это какой-то отладочный ToString.
Офигеть! Выглядит классно!
Кажется, что с таким эффектом элементы окружения более различимы, чем без него.
Или Вы будете «парсить» сайты авиакомпаний? У многих есть защита на кол-во запросов от одного и того же IP-адреса.
Вы увидели только малую часть той великолепной дороги (полностью асфальтированной, кстати) с прекрасными пейзажами, скозь высокогорные луга с коровками и овечками, иногда сквозь облака, а в конце дороги вот: