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

Как известно, некоторые российские госкомпании сейчас под санкциями, в том числе эмитентами сертификатов. Сбер уже перешёл на сертификаты от Минцифры. Ростелеком, вероятно, к ноябрю 2024 года тоже перейдёт. А CA Минцифры соответственно рукопожат только браузерами Яндекс Браузер и Atom.

У этой проблемы есть несколько решений.

Использовать Яндекс Браузер или Atom с уже установленными сертификатами Минцифры и горя не знать.

Сохранить корневой сертификат Минцифры в доверенные для всей операционной системы (и всех браузеров), если вам совсем нечего скрывать.

Использовать браузер Firefox с выделенным пользовательским профилем под Рунет.

Использовать виртуальное окружение для любимого браузера с нелюбимым сертификатом Минцифры. (не могу найти ту публикацию).

Запускать браузер от имени другого пользователя.

Статья собственно о третьем методе.

В этой статье мы собираемся разобраться со следующими вопросами:

* Как виртуализировать сетевые ресурсы, чтобы контейнеры думали, что у них есть отдельные сетевые среды?

* Как превратить контейнеры в дружелюбных соседей и научить общаться друг с другом?

* Как выйти во внешний мир (например, в Интернет) изнутри контейнера?

* Как связаться с контейнерами, работающими на хосте Linux, из внешнего мира?

* Как реализовать публикацию портов, подобную Docker?

Всем привет! Меня зовут Катя Муличева, я тестировщица в СИБУР Диджитал. Последние два года я пишу автотесты для gRPC на Kotlin. Получив опыт, я захотела написать статью, которая очень пригодилась бы мне самой, когда я только начинала разбираться с gRPC. Надеюсь, вы найдете её полезной для себя!

В этот раз я достаточно внимательно прочитал перевод главы про задачи(Tasks) из этого Поста, чтобы выяснить, что он не очень точно передает смысл исходного текста. Я попробую пересказать содержание так, как я его понял, в том числе полагаясь на свой практический опыт программирования многопоточных приложений и embedded приложений с множеством прерываний.

Мне кажется, я придумал хороший формат, чтобы совместить свой пересказ содержания достаточно близко к смыслу исходного текста (надеюсь), с моими комментариями-разъяснениями-догадками.

Пару ссылок на предыдущие работы по этой теме вы тоже найдете под катом.

Теорема (формула) Байеса позволяет выяснить вероятность события при условии, что произошло связанное с ним другое событие.

Теорема позволяет рассчитать вероятность события, если причину и следствие поменять местами. Например, мы знаем распространенность симптома среди больных и здоровых. Значит, мы можем вычислить вероятность заболевания от наличия симптома.

Как вы наверняка знаете, LINQ (Language Integrated Query) - это очень мощный и гибкий язык, встроенный в C# и существует он начиная аж с .NET Framework 3.5. Однако, несмотря на свои возможности, синтаксис запросов часто игнорируется в пользу более популярного аналога - синтаксиса методов. Хотя синтаксис методов действительно мощный, в этой статье я на практических примерах покажу преимущества query-синтаксиса и его полезность для опытных разработчиков на C#.

Хабр, привет!

Сегодня я предлагаю совершить небольшое исследование на тему "как нам обустроить интеграционное тестирование и встроить его в сиайку".
Написать эту заметку меня сподвигла дискуссия, случившаяся недавно на работе. Инициативная группа "четырехглазых в свитерах" пыталась родить меры по улучшению качества нашего изделия и снижения трудозатрат QA-инженеров на проведение рутинного регрессионного тестирования. Как это часто бывает, разработчики если и писали тесты, то только модульные, оставляя интеграционные и end-to-end для тестировщиков. Для выполнения интеграционного тестирования QA-инженеры используют "тестовый стенд", на котором развернуты компоненты приложения (еще около 40, с позволения сказать, "микросервисов"), сервер базы данных (с не всегда ясным наполнением этой самой базы), брокер сообщений (RabbitMQ) и все остальное, что может потребоваться для запуска приложения. На этот тестовый стенд натравливаются автотесты, которые шатают приложение за все доступные снаружи конечные точки, таблицы БД и элементы UI пытаясь проверить максимальное количество тестовых сценариев в границах (и за ними!) возможных входных данных.

Всем привет! Я QA Engineer и недавно открыл для себя ChatGPT и хочу открыть этот мир другим тестировщикам. Эта статья не руководство к применению и каких-то суперлайфхаков здесь не будет. Цель этой статьи в том, чтобы показать огромные возможности нейросетей в помощи нам, тестировщикам, в работе. Надеюсь что кто-то, прочитав это, хоть немного сможет облегчить себе составление тест-кейсов, написание документации или написание автотестов. Примеров с написанием кода здесь по минимуму, так как таких материалов уже много.

Или максимы Английского языка, которые бы я хотел знать 20 лет назад.

Чем отличается хороший геймер от плохого? Хороший геймер сидит и изучает игру. Он знает каждый закуток. Он может без запинки назвать все характеристики всех юнитов в Star Craft. А самый крутой игрок знает все пропускные способности желтых, красных и синих конвейеров. А плохой игрок использует чит-коды или assistant apps. 

Можно сколько угодно сидеть и жаловаться о том, что правила сложны. А можно просто взять, изучить эти правила и уделать наисложнейшую игру.

Я не раз в своей жизни слышал, что Английский чрезвычайно сложен. Подобные заявления фактически являются чит-кодом. Вы просто сдаётесь и перестаёте пытаться. А зря. В английском языке есть очень много полезных и понятных вещей. 

В этой статье я хочу вам показать основные моменты, которые помогли мне хорошо овладеть языком. И надеюсь, что понимание этих моментов поможет и вам. 

Часто люди, отчаявшись добиться желаемого прогресса после многих лет нерационального изучения языка, делают вывод: «Учу-учу, ничего не получается… Что-то идёт не так. Наверно, сделать качественный рывок мне поможет только погружение в языковую среду».

Покупают курс в Лондоне. Возвращаются с отличными впечатлениями, почти без денег и растущей убеждённостью: «Мой случай уникален, нужен какой-то особый подход».

Ни черта уникального на самом деле нет, ситуация очень типичная. Всё это — от тотального повсеместного непонимания, из чего, собственно, состоит знание иностранного языка. Да и разобраться непросто — весь эфир забит рекламной демагогией. 9 из 10 жалуются: я плохо воспринимаю речь на слух… что делать… У рекламщиков ответ уже готов: «Улучшить восприятие на слух? — Не проблема! Приходите! Поможем!»

Ну приходят. Заканчивается всё очередным разочарованием и ещё более глубокой убеждённостью в «уникальности» своего случая. В общем, давайте разберёмся, из чего состоит «знание» иностранного языка.

Во-первых, не верьте знакомым, которые говорят, что хорошо понимают носителей на слух. Носители сами друг друга часто переспрашивают, даже понимая контекст разговора. И если ты не вырос в Англии, у тебя ВСЕГДА будут проблемы с восприятием речи британца. Сейчас расскажу, почему.

Вспомните ситуации, когда вы понимали носителя, пока он говорит с вами, но мгновенно переставали его понимать, когда он начинал говорить с другим носителем. Как так?

Реальные живые носители произносят не совсем те слова, которые мы ожидаем услышать, читая субтитры. Ни в одном словаре нет слова forya (ударение на первый слог), а оно, между тем, распространённое (в субтитрах будет написано for you). Не менее распространено слово whaddaya (в субтитрах пишут what do you). То же самое происходит в скоростной русской речи: вместо «он говорит» в реальной жизни мы обычно используем слово «онгрьт» с невнятной «н». Очсомневаюсь, что оно есть в словаре. Однажды при мне темнокожий парень объяснял посреди Москвы темнокожей девушке: «…and instead of “shto” they say “chyo” (вместо «што» они говорят «чё»). «Чё» даже не похоже на «что».

Одно из знаковых событий 2022 года помимо text-to-image моделей - это, безусловно, модель ChatGPT. Выйдя на суд общества, она смогла найти как большой круг почитателей и восхищающихся её способностями, так и довольно существенное число скептиков и борцов за торжество Естественного Интеллекта. Мы провели своё небольшое исследование её возможностей, проверили часть фактов, публикуемых в Интернете относительно ошибок и предвзятостей ChatGPT, и рады этим поделиться.

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

Два года назад я задался вопросом "Как мне все успевать?". Вопрос пришел в веселой компании усталости, прокрастинации и выгорания...

На связи Саша Хрущев, технический директор IT-компании WINFOX. Мы открыли филиал в Боснии и Герцеговине и рассказываем, как жить и работать в этой стране. В этой статье — про то, как жить в этой стране после переезда: правила пребывания, стоимость жизни, жилье, транспорт, язык и другие особенности.

Привет! Меня зовут Макс Нечаев и я iOS-разработчик. Буквально два года назад я абсолютно не понимал реального значения тайм-менеджмента. Это привело меня к крайне неэффективному использованию своего времени, выгоранию и ряду переживаний.

В данной статье я хочу помочь вам разобраться со своим временем и попробовать его структурировать. Раз вы читаете эту статью, значит вы как минимум уже заинтересовались вопросами управления своим днём.

На самом деле менеджмент времени - это не про использование задачников, таймеров или блокнота...

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

Да-да, это именно разработка собственного роутера, не простой допил уже имеющегося и переупаковка в другой корпус. Отнюдь! Схема, печатная плата, пайка – всё сделаем сами и защитим диплом. Заинтересовал?

Я работаю техническим писателем в компании documentat.io. Мы занимаемся заказной разработкой технической документации, в том числе на английском языке. Иногда я дорабатываю уже существующие документы или спецификации к API на английском. Как правило, такие документы написаны русскоязычными разработчиками, которые неплохо владеют английским. И всё же они часто допускают характерные грамматические, пунктуационные и стилистические ошибки.

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

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

В этой статье я хочу рассказать о том, как расширяются возможности ASP.NET Core по обработке запросов к веб-серверу с помощью самостоятельно написанных компонентов конвейера обработки.

Обычно для разработки серверной части веб-приложений (по-простому — бэка) с помощью ASP.NET Core имеет смысл использовать базирующиеся на нем фреймворки высокого уровня: MVC Core, Razor Pages и т.д.: они позволяют с минимумом усилий решать типовые задачи. Но встречаются задачи нетиповые, которые требуют для своего решения перейти на более низкий уровень (или, по крайней мере, понимать, что на этом уровне происходит) — на уровень базовых возможностей ASP.NET Core. И в этой статье как раз рассказывается об использовании одной из этих базовых возможностей — компонентов middleware, из которых создается конвейер обработки запросов к веб-серверу. Далее в статье я буду называть их компонентами-обработчиками, потому что официальный перевод из документации от MS — "ПО промежуточного слоя" — он некрасив и не описывает их функции. Конкретно в статье рассматривается, какие средства предоставляет фреймворк ASP.NET Core для создания самописных компонентов-обработчиков. И особое внимание уделено тому, как эти компоненты могут получить доступ к другой базовой возможности ASP.NET Core — сервисам, которые зарегистрированы в контейнере сервисов (он же — "DI-контейнер"), как к стандартным для ASP.NET Core, так и к самописным.

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

Вот мой список 5-ти лучших Agile-практик, на которые уходит много времени и которые бесполезны:

1. Оценка пользовательских историй в Story Points по конечным результатам.

Единственная причина оценки в Story Points - проверить, есть ли у команды одинаковое понимание того, что и как нужно сделать для завершения User Story. Оценка любой работы методом от обратного контрпродуктивна и не приносит никакой пользы: Какой смысл проверять, одинаково ли мы понимаем то, что уже сделано? Кроме того, это подрывает правильное использование Story Points на сессиях планирования.

Promise — это отличительная особенность JavaScript как асинхронного языка программирования. Нравится вам это или нет, понять его в любом случае придется. В этой статье я привожу 10 примеров кода с Promise, начиная от базового уровня заканчивая продвинутым.