Разработчик
Copilot – система автодополнения кода от GitHub на основе модели Codex.
В статье даю советы по эффективному использованию Copilot на основе 6 месяцев личного опыта. Также добавил инструкцию по установке из России.
Tldr: Copilot подходит для повторяющихся задач и как замена поиску по документации популярных библиотек. Помогает быстрее писать код. Не подходит для решения узких сложных задач и проектов с нуля.
Поговорим о бенчмаркинге кода: о том, что это такое и для чего нужно. А также покажем, как на основе результатов бенчмаркинга оценить производительность кода в проекте, написанном на C#.
System.Collections.Concurrent настолько, насколько это возможно, включая примеры и сценарии использования. Также будет затронута тема сравнения с неизменяемыми (immutable) и замороженными (frozen) коллекциями.
Рассказываю о своём опыте использования Xray (с протоколом VLESS-Reality) - одного из лучших решений для преодоления интернет-цензуры на сегодняшний день. Я потратил много времени на то, чтобы разобраться с ним - теперь вам достаточно одного вечера, чтобы поднять свой сервер на несколько десятков пользователей, c xray на борту!
• скрипт ex.sh для простой настройки и установки; есть поддержка Docker
• легко добавлять пользователей; клиентские конфиги в форме url-ссылок
• правильные конфиги: скрытность + удобство
• трафик популярных российских сайтов идёт напрямую, a не через сервер
• для xray есть приложения под все популярные ОС - делюсь инструкциями
• только https, нет udp; торренты через сервер блокируются по возможности
• мой проект на гитхабе: easy-xray
В этой статье я опишу как написать тесты для компонентов Angular приложения, используя инструменты которые предлагает нам Angular из коробки.
Эта статья - базовое описание того, из каких компонентов состоит Kubernetes, как он работает «под капотом». Это важно так как платформа сложная и:
• понимание ее работы влияет на факторы разработки;
• становится понятно, что можно и чего нельзя;
• помогает объяснить, почему одно не работает;
• или почему другое работает не так, как ты рассчитываешь.
Kubernetes настраивается с помощью YAML-ов и сам состоит из нескольких независимых компонентов (поддерживает свою же идею). Сами компоненты написаны на Go.
Внутреннюю структуру можно рассмотреть с разных сторон, что мы и сделаем в этой статье.
Поддержка в рабочем состоянии заданного набора контейнеров является одним из главных преимуществ использования Kubernetes
В этой статье я хотел бы на практике разобраться в этом аспекте, а именно в том как проверяются живы ли контейнеры и как они перезапускаются в случае необходимости, а также как нам, разработчикам приложений, помочь системе оркестрации в этом деле
Алексей Барабанов, IT-директор «Хлебница» и спикер курса «RabbitMQ для админов и разработчиков», подготовил конспект, который поможет научиться запускать и настраивать RabbitMQ в Docker. Вы поймёте, как конфигурировать параметры запуска, а также узнаете о возможностях управления через веб-интерфейс.
Перевод обновлённого гайда Android по архитектуре приложений. Это — первая часть из пяти: обзор рекомендаций по архитектуре.
Порой мы халатно относимся к безопасности, не выделяем для неё достаточно времени, потому что "да что может случиться". На примере Васи, нашего веб-разработчика, мы покажем, что лучше ей не пренебрегать. Хотя бы базовыми её принципами.
Меня зовут Николай, я Frontend-разработчик IT-компании Relog. Хочу рассказать о самых распространённых ошибках в вёрстке современных проектов.
Дело в том, что лишь малая часть современных фронтендеров обращает внимание на работу с HTML и CSS, предпочитая готовые решения, вроде UI-библиотек и систем сеток. Но эти решения неидеальные и приходится дописывать обёртки вокруг них, видоизменять код, переписывать стили и совершать прочие действия для соответствия требованиям проекта. Тут-то и начинаются проблемы: вёрстка местами становится избыточной, стили переназначются через important и с каждым релизом проект всё сложней поддерживать. Я уже не говорю об удобстве использования и доступности. Об этом думают вообще в последнюю очередь.
В этой статье я расскажу лишь о небольшой части проблем, которые можно достаточно быстро решить, не прибегая к радикальному переписыванию больших частей проекта.
В предыдущей публикации мы рассмотрели некоторые базовые вопросы относительно потоков и пулов потоков и готовы двигаться дальше. Давайте проведём эксперимент и найдём правильный объём работы для пула потоков. Чтобы его издержки не давлели над объёмом полезной работы
⚠️ Материал средней сложности
С другой стороны, показанные примеры доказывают, что на производительность сильно влияет гранулярность элементов работы. Имеется ввиду, конечно же, длительность работы делегатов. Чтобы достичь хороших показателей, гранулярность работы не может быть абы какой: она должна быть правильной. И помимо планирования задач на ThreadPool, планировать их можно также как через TPL так и через какой-либо свой собственный пул потоков. Например, если взять обычный ThreadPool, то можно примерно измерить издержки алгоритмов ThreadPool в тактах Time Stamp Counter счётчика времени (можно, конечно и в чём-то более привычном типа микросекунд, но там на многих сценариях вполне могут быть нули)
Эта текст покрывает ответы на некоторые совсем базовые вопросы и вместе с тем сразу погружает в проблематику получения ответа на вопрос: "как работать лучше? однопоточно, многопоточно или многопоточно, но на ThreadPool?". Ответ на этот вопрос может изначально показаться очень простым и понятным, однако реальность совершенно иная: всё как и везде сильно зависит от ситуации: от типа задачи, от её размера, от прочих условий, которые так просто в голову сами собой не придут.
А потому мы пройдёмся в первую очередь по IO-/CPU-bound операциям, стоимости создания потока, базовым основам работы пула потоков (но только основы), а далее -- углубимся в анализ чёрного ящика: от чего зависит производительность пула потоков? Каков объём работы приемлим для того чтобы в него планировать?
Закончим мы главу несколькими, возможно, пугающими выводами об объемах работы, приемлимой для того чтобы обеспечить производительную работу приложения на пуле потоков.
Также отмечу, что материал постепенно переходит от начального уровня сложности 🥤 через ⚠️ средний уровень к ☠️ высокому, о чём вы сможете узнать по пиктограммам.
TypeScript — это язык, расширяющий JavaScript, добавляя в последний типизацию. Правда, так как TypeScript не имеет runtime-а (почти), он транслируется в JavaScript, в процессе чего, вся типизация теряется. Такую типизацию можно назвать лишь инструментом статического анализа кода. Тем не менее — это очень мощный инструмент. К тому же, помимо проверки кода, типизация также и документирует его.
В данной статье я расскажу лишь про типы, объявленные через ключевое слово type, не касаясь интерфейсов и классов. Однако, эта тема шире, чем может показаться, и я надеюсь, что читатель узнает что-то новое для себя. Ведь с помощью type можно писать маленькие программки (далее, утилиты), которые выполняются в процессе статического анализа кода, расширяя его возможности.
При написании стилей необходимо сразу учитывать, что контент страницы может быть динамическим, чтобы не возникла ситуация, где мы добавили чуть больше текста, или уменьшили ширину экрана, и вёрстка поплыла. Статья состоит из примеров универсальных CSS-стилей для часто встречающихся ситуаций. Рекомендуется к прочтению верстальщиком начального и среднего уровня.
В моем предыдущем посте я рассмотрел код WebApplicationBuilder, включая некоторые из его вспомогательных классов, таких как ConfigureHostBuilder и BootstrapHostBuilder. В конце поста мы создали экземпляр WebApplicationBuilder и вызвали Build() для создания WebApplication. В этом посте мы немного рассмотрим код, лежащий в основе WebApplication, и сосредоточимся на настройке промежуточного ПО и конечных точек.
В этой статье поговорю про основы работы с Postman для начинающих тестировщиков. Сама я столкнулась с этим инструментом как раз на последнем проекте.
Расскажу, как с его помощью создавать простейшие автотесты и уменьшать объем рутины с помощью переменных.