Прошли те времена, когда фронтендеру достаточно было открыть «Блокнот», написать несколько строк кода, проверить его в браузере и загрузить на сервер через FTP. Современная разработка пользовательского интерфейса сильно усложнилась. Экосистема JavaScript растет и изменяется настолько стремительно, что в ней легко запутаться. В этом посте я расскажу, что использует фронтенд-команда Parallels для оптимизации работы.Читать полностью »
Всем привет!
Я работаю бэкенд-разработчиком в компании Tinkoff, где участвую в разработке платформы CRM-системы для обслуживания физических и юридических лиц.
Использование edge proxy и балансировщика в частности — это почти мастхэв при построении современных систем. Сегодня на рынке представлено большое количество разнообразных решений, у каждого из которых есть преимущества и недостатки. Мы остановимся на одном из самых свежих — Envoy.
Envoy — это высокопроизводительный балансировщик, реализованный на C++. Его разработала компания Lyft — сервис заказа такси в Штатах, прямой конкурент Uber — для использования как с отдельными сервисами, так и в качестве связующего звена в сложных микросервисных системах. В том числе для реализации относительно свежего архитектурного явления — service mesh.
Формируя основной фундамент нашей платформы, он реализует cors, access-control, rate limiting, outlier detection, проверку jwt и многое другое.
На Хабре есть отличная статья, которая разбирает его основные отличия от ближайших соседей и проливает свет на внутреннее устройство. Мы же сфокусируемся больше на прикладных моментах, разберемся с запуском и настройкой, попробуем сразу несколько видов балансировки трафика. Поехали!
Как чинить баги, если вы — органический продакшн с аптаймом в десятки лет, когда нельзя сделать ни ребут, ни замену внутренних модулей? Почему переиспользование кода — это логично, но печально? Отчего нельзя выключить какой-нибудь белок и стать неуязвимым к ВИЧ или SARS-CoV-2?
Не знаю как вы, а я люблю ковыряться в кишочках разных систем. И в этой статье хочу рассказать о внутреннем устройстве Lua-таблиц и их особенностях. Lua — мой основной язык программирования по долгу службы, и чтобы писать хороший код, надо хоть немного понимать, что происходит за кулисами. Любопытных прошу за мной.
Представляем Windows Terminal v0.10! Как и всегда, вы можете загрузить его из Microsoft Store, либо со страницы релизов на GitHub. Под катом подробнее рассмотрим детали обновления!
В процессе подготовки к курсу «Основы компиляторов» для студентов 4-го курса я изучал различные эзотерические языки программирования. Вот хорошая статья на эту тему. В статье самым интересным мне показался язык Befunge (Крис Пресс, 1993 год), особо отмечу три его особенности:
В Unix-подобных операционных системах общение программы с внешним миром и операционной системой происходит через небольшой набор функций — системных вызовов. А значит, в отладочных целях полезно бывает подсмотреть за выполняемыми процессами системными вызовами.
Следить за «интимной жизнью» программ на Linux помогает утилита strace, которой и посвящена эта статья. К примерам использования «шпионского» оборудования прилагаются краткая история strace и описание устройства подобных программ.
На днях вышла прекрасная, хотя и спорная статья — Please, stop using GitFlow! (и еще десяток на эту же тему после нее).
Ее основными тезисами были:
Но проблема GitFlow в том, что он и с монорепозиториями тоже не дружит.
Я сам об это споткнулся в процессе дизайна пайплайнов CI: GitFlow чудовищно мешает, когда работает поверх монорепозитория с несколькими deliverables, например, когда в одном репозитории отдельно и бэкэнд, и фронтэнд — уже из-за того, что он позволяет докоммичивать в релизные ветки, могут возникнуть конфликты при обратном мердже, если в один момент времени существует больше, чем одна релизная ветка. Да даже если одна, все равно плохо — в таких условиях надо патчить в принципе релизные механизмы GitFlow, чтобы хоть как-то заработали отдельные релизы сущностей.
В конце прошлого года мы выпустили .NET Core 3.0 и 3.1. В этих версиях добавлены модели настольных приложений Windows Forms (WinForms) и WPF, ASP.NET Blazor для создания одностраничных приложений и gRPC для кроссплатформенного обмена сообщениями на основе контрактов. Мы также добавили шаблоны для создания сервисов, крутое генерирование клиентского кода для общения с gRPC, сервисы REST API и многое другое. Мы рады, что .NET Core 3 стала самой быстро-принятой версией .NET, и за последний год у нас появился еще миллион пользователей.
Мы также работали над этими выпусками, чтобы завершить перенос моделей приложений из .NET Framework. В .NET Core 3 мы перенесли все наиболее используемые модели приложений, а также представили новые кроссплатформенные инфраструктуры вместо тех, которые не были портированы.
В ожидании следующего основного выпуска .NET 5 мы продолжим объединять .NET в единую платформу, включив нашу модель приложения для мобильных устройств .NET (Xamarin) в .NET 5. .NET 5 будет включать ASP.NET Core, Entity Framework Core, WinForms, WPF, Xamarin и ML.NET. Впервые вся платформа будет использовать унифицированный BCL (библиотеки базовых классов) для всех моделей приложений. Наличие версии 5, которая выше, чем у .NET Core и .NET Framework, также дает понять, что .NET 5 — это будущее .NET, единой унифицированной платформы для создания приложений любого типа.
Мы говорили это много раз, но мы еще раз повторим; .NET Core, а затем .NET 5 — это .NET, с помощью которого вам стоит создавать все свои новые приложения. .NET Framework будет поддерживаться до тех пор, пока поддерживается сама Windows. Мы будем продолжать обеспечивать безопасность и исправлять ошибки, а также обновлять сетевые и крипто API. Он будет оставаться безопасным и поддерживаться для работы ваших старых приложений на .NET Framework.
Программисты много говорят про сложность решений. Мы можем часами размышлять о правильных шаблонах, красивых абстракциях и цепочках зависимостей. Однако, давайте поговорим открыто, всегда ли сложность обусловлена решаемой проблемой? Не оказываемся ли мы в плену наших стереотипов и убеждений?
