User
Данная статья содержит небольшое введение в JIT-компиляцию и .NET Core (отныне .NET 5, .NET 6 и так далее), а также несколько практических примеров ускорения запуска приложений на .NET. Данные советы могут быть полезны как для приложений, запускаемых на больших многоядерных x64 серверах, так и для приложений, запускаемых на ARM чипах с малым числом ядер. Например, подобные оптимизации используются в операционной системе Tizen, об этом далее.
Инструкция по диагностике проблем в работе баз данных в случае аварии.
Привет. У каждого на работе иногда случаются «чёрные» дни. Для меня такими днями являются аварии в работе сервисов, приводящие к недоступности систем для конечных пользователей. По счастью, такое происходит нечасто, но каждый такой случай заставляет меня долго рефлексировать над вопросами «что мы сделали не так».
После одной из аварий я поймал себя на мысли, что диагностика причины недоступности сервиса заняла слишком много времени. Инженеры, задействованные в разрешении инцидента, действовали не совсем скоординированно: проверяли одни и те же гипотезы и тратили время на изучение совсем уж «фантастических» вариантов. В квалификации ребят никакого сомнения у меня нет, поэтому в рамках рефлексии я списываю это на стрессовую ситуацию аварии.
Чтобы в следующий раз диагностика и устранение причин аварии происходили быстрее, мы совместно с DevOps-инженером Алексеем Поповым решили написать «план эвакуации при пожаре»: пошаговую инструкцию, которую можно было бы использовать для быстрого исследования инцидента.
Последняя проблема касалась работы базы данных и взаимодействия web-приложения с базой. Поэтому инструкция касается диагностики именно базы данных. Также хочу отметить, что эта схема — не истина в последней инстанции, а всего лишь наш опыт, перенесенный на «бумагу». Мы намеренно не стали включать слишком «экзотические» причины аварии, поскольку схема становится слишком громоздкой и нечитаемой.
Я буду признателен за комментарии и описания аналогичных проблем, которые происходили у вас.
Мой переход на F# в качестве излюбленного языка был слегка усеян препятствиями. Примерно через десять лет почти постоянного использования C# у меня пробудилось любопытство, когда я услышал об этом другом #-языке. Моя первая реакция была той, которую с тех пор видел у других C#-разработчиков — отрицание, — C# является хорошим языком, и мне с ним комфортно, так зачем тратить силы на изучение другого? Но любопытство осталось — и, по крайней мере, несколько раз выделил вечер, чтобы прочитать базовый вводный пост и попытаться написать каких-нибудь ката на F#. Это не прижилось, потому что я просто чувствовал себя потерянным и не мог воплотить свой опыт использования C# в ощущение даже отдаленного комфорта с F#. Достаточно легко опустить фигурные скобки, немного замяться, чтобы не забыть let вместо var — но как сделать то, что я хотел?
Тогда я этого не осознавал, но, на мой взгляд, наблюдал потенциальный недостаток в том, как F#-разработчики говорят, описывают и представляют свой язык внешнему миру. Существует обширная база материалов обо всех возможностях и функциональности F#: Algebraic Data Types, Exhaustive Matching, Type Inference и т.д. Есть много статей, посвященных тому, как решать широкий спектр задач с помощью F#. Но, как мне кажется, не хватает чего-то вроде следующего: некоторых указаний о том, как взять то, что вам уже удобно в C#, и перевести их на F#. Так что мне интересно, можем ли мы как-то закрыть этот недостаток.
Мы живем в удивительное время — каждый становится экспертом, прочитав пару статей из интернета. Есть, конечно, сферы жизни, в которых мы были экспертами всегда, еще задолго до появления всемирной сети. Например, футбол, хоккей, отношения и управление страной.
Но теперь мы дополнительно освоили и специальности, требующие специфических знаний. Например, медицина. Google в помощь — и вот мы поправляем врачей, сами ставим себе диагноз и назначаем лечение. И только когда совсем уже худо, когда петух непрерывно начинает клевать в то место, где спина теряет свое благородное название, мы бежим к врачу, которому приходится не только лечить запущенную болезнь, но и бороться с последствиями нашего интернет-лечения.
Подобная ситуация и с налогами. Интернет пестрит всевозможными советами, как и что делать во время налоговой проверки, очень часто прямо противоречащими друг другу.
Кто-то советует сразу включить видеокамеру и диктофон, кто-то предлагает выделить кабинет с чайником, СВЧ-печью и заполненным холодильником. Одни предлагают свести устное общение к минимуму, другие дают советы, как расположить к себе, в стиле «называйте чаще по имени», «делайте комплименты, но не льстите», «попросите совета на будущее». Одни советы слишком общие, другие излишне конкретизированные, а некоторые вообще опасны и могут привести к негативным и непредсказуемым последствиям.
Испытывая желание нести знания в массы и искренне переживая за налоговое здоровье наших сограждан, мы тщательно проанализировали имеющуюся информацию о проведении налоговых проверок, а также обобщили наш 10-летний опыт сопровождения налоговых проверок.
Наша задача — определить конкретные правила поведения, алгоритм действий налогоплательщика, результатом выполнения которых будет минимизация возможных доначислений.
Обратите внимание — именно минимизация, так как доначисления, конечно, будут. «Нулевые» проверки — это нонсенс. Ведь от эффективности проверок зависят показатели инспекции и, соответственно, премирование сотрудников. Поэтому доначисления будут, но то, в каком объеме и, самое главное, будут ли у вас основания их оспорить в суде, во многом зависит от качества ваших действий во время налоговой проверки.
Это часть 1 из серии 2 частей практического руководства по HashiCorp Consul. Эта часть в первую очередь ориентирована на понимание проблем, которые решает Consul и как он их решает. Вторая часть больше ориентирована на практическое применение Consul в реальном примере и будет опубликована на следующей неделе. Давайте начнем.
В статье представлены обобщённые подходы применения конвертеров значений при написании XAML-кода.
Человеческая жизнь слишком коротка, чтобы тратить ее на интеграцию и документацию. С помощью контрактов и кодогенераторов можно сократить рутинные операции и переписывание кода, обеспечить недосягаемое иными способами покрытие и достигнуть невыразимой чёткости бытия тестировщиков, разработчиков и систем.
Я занимаюсь автоматизацией тестирования в Яндексе с 2013 года. Из них более четырёх лет автоматизирую тестирование REST API-сервисов. На Heisenbug я рассказал об использовании OpenAPI-спецификации как основы для приёмочных тестов, а также о том, как легко поддерживать автотесты на огромное количество REST API-сервисов и добавлять автотесты на новые проекты.
Под катом — видеозапись и расшифровка моего доклада. Примеры из доклада есть на GitHub.
В этой статье, на примере простых логических выражений, будет показано, что такое абстрактное синтаксическое дерево и что с ним можно делать. Так же будет рассмотрена альтернатива выражениям LINQ для выполнения запросов к SQL базам данных.
Программист ставит себе на тумбочку перед сном два стакана. Один с водой — на случай, если захочет ночью пить. А второй пустой — на случай, если не захочет.Давайте разбираться — когда сортировка в запросе точно не нужна и несет с собой потерю производительности, когда от нее можно относительно дешево избавиться, а когда сделать из нескольких — одну.
