ssh terminal.shop

ssh 172.65.113.113

В свое время я случайно узнал, что исключения в моём горячо любимом языке C# — и, как следствие, во всем .NET — не все ведут себя одинаково. Причём, что ещё гораздо интереснее, далеко не все и не всегда могут быть обработаны и перехвачены. Что, казалось бы, полностью противоречит интуитивному восприятию конструкции try-catch-finally. 

Изучая этот вопрос, я находил всё новые и новые исключения среди исключений, которые оказывались «сильнее», чем конструкция try-catch-finally. К тому моменту, когда мой список вырос до 7 пунктов, я внезапно осознал, что нигде не было такого места, где можно было бы найти их все сразу. Максимум — 2 или 3 случая, рассмотренных в одной статье. 

Это и подтолкнуло меня к написанию данной статьи. 

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

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

Copilot – система автодополнения кода от GitHub на основе модели Codex.
В статье даю советы по эффективному использованию Copilot на основе 6 месяцев личного опыта. Также добавил инструкцию по установке из России.

Tldr: Copilot подходит для повторяющихся задач и как замена поиску по документации популярных библиотек. Помогает быстрее писать код. Не подходит для решения узких сложных задач и проектов с нуля. 

Поговорим о бенчмаркинге кода: о том, что это такое и для чего нужно. А также покажем, как на основе результатов бенчмаркинга оценить производительность кода в проекте, написанном на C#.

Рассказываю о своём опыте использования 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. Вы поймёте, как конфигурировать параметры запуска, а также узнаете о возможностях управления через веб-интерфейс.

Плюсы микро-фронтенд архитектуры

• Автоматизация CI /CD. Поскольку каждое приложение интегрируется и развертывается независимо, это упрощает CI/CD. Так как все модули разделены, то не нужно беспокоиться обо всем приложении при внедрении нового модуля. Если в коде модуля есть ошибка, CI/CD прервет весь процесс сборки.
  Гибкость команд разработчиков. Многочисленные команды могут разрабатывать и развивать информационные системы, работая по отдельности.
• Единая ответственность. Каждая команда микро-фронтеда на 100% фокусируется на функциональности своего микро-фронтенд приложения.
• Возможность повторного использования. Микро-фронтенд приложение может быть повторно использовано несколькими командами в разных системах.
• Технологический агностицизм. Архитектура микро-фронтенд не зависит от технологии. Возможно использовать компоненты, разработанные на разных фреймворков веб-разработки (React, Vue, Angular и т.д.).
• Простой порог входа в систему. Небольшие модули легче изучать и понимать новым разработчикам, входящим в команды, чем монолитную архитектуру с огромной структурой кода.

Перевод обновлённого гайда 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 можно писать маленькие программки (далее, утилиты), которые выполняются в процессе статического анализа кода, расширяя его возможности.