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

Планируется, что Angular 18 будет выпущен в мае 2024 года, и уже есть несколько подтвержденных функций для включения в предстоящую версию, которые мы рассмотрим в данном материале.

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

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

Интероперабельность необходима для использования уже существующих библиотек, написанных на C, C++ или других языках, которые выполняют важные или высокопроизводительные функции. Таким образом открывается возможность интеграции .NET-приложений с различными системными компонентами и устройствами, доступ к которым возможен только через нативные API.

В основе интероперабельности лежит взаимодействие управляемого кода. Управляемый код исполняется под управлением CLR — виртуальной машины .NET, которая обеспечивает такие возможности, как сборка мусора, безопасность типов и другие виды абстракции. А вот нативный код компилируется напрямую в машинный код, специфичный для конкретной платформы, и исполняется ОС без промежуточных слоев, что обеспечивает высокую производительность и прямой доступ к ресурсам системы...

Игнорируете кастомные директивы в Angular? Зря-зря, многое упускаете.

Позвольте мне показать в нескольких статьях, как с помощью директив можно расширить функционал ваших компонентов, да так, что никакой DX не пострадает (а только улучшится) (по моему мнению). Представляю вам набор паттернов, которыми пользуюсь я.

«ООП для меня означает лишь обмен сообщениями, локальные ограничения и защиту, сокрытие состояния процесса и крайне позднее привязывание», — Алан Кэй (человек, придумавший термин «объектно-ориентированное программирование»)¹

Привет, Хабр! На связи разработчик АО АльфаСтрахование. В этой статье я хочу рассказать о мультиаутентификации в ASP.NET Core приложениях.

Нам довольно часто нужно писать .NET Core приложения. Нередко они используются для интеграции крупных систем. А в этих системах частенько свой собственный набор учетных записей (далее УЗ) и инструментов по управлению доступа к ним.

При создании интеграции у нас часто возникает проблема, когда в рамках одного запроса нужно нужно аутентифицировать 2 и более учетных записей

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

Но червь овладел одной задачей, которая до сих пор не удавалась величайшим умам человечества: идеальной регенерацией. Если разорвать его пополам, из головы вырастет новый хвост, а из хвоста — новая голова. Через неделю два здоровых червяка уплывут.

Выращивание новой головы — хитрый трюк. Но биолога Майкла Левина из Университета Тафтса интригует именно хвостовая часть червя. Он изучает, в частности, как организм развивается из отдельных клеток, и его исследования заставляют его подозревать, что разум живых существ, как ни странно, находится за пределами их мозга. Например, в клетках задней части тела червя может находиться довольно развитый «интеллект». «Любой интеллект — это коллективный интеллект, потому что любая когнитивная система состоит из каких-то частей», — говорит Левин. Животное, способное пережить полную потерю головы, стало для Левина идеальным подопытным.

Продолжаем серию «C++, копаем вглубь». Цель этой серии — рассказать максимально подробно о разных особенностях языка, возможно довольно специальных. Это шестая статья из серии, список предыдущих статей приведен в конце в разделе 7. Серия ориентирована на программистов, имеющих определенный опыт работы на C++. Данная статья посвящена объявлению и инициализации переменных.

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

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

На уходящей неделе мне попалась симпатичная, хоть и не новая мини‑серия статей на Дзен‑канале @zdgzdgzdg про процедурную генерацию лабиринта методом «коллапса волновой функции». Пока я читал эти статьи и знакомился с кодом, меня осенило: ведь это же вычисления в комонаде, погружённые в монаду! Я не издеваюсь, действительно, речь идёт о композиции двух паттернов функционального программирования: комонады Zipper, превращающей локальные правила в глобальное состояние, и монады Random, позволяющей генерировать случайные объекты.

И вот, в качестве баловства на выходных, я решил реализовать этот «квантовый» алгоритм генерации лабиринтов на Haskell, используя и комонады и монады, и вообще, ни в чëм себе не отказывая. И хотя язык программирования Haskell нужен не только для извращений, но именно для них он подходит идеально!

Полезный алгоритм построения плоскости по облаку точек МНК. Я проверял этот алгоритм на устойчивость к самым разным наборам входных данных.

Мне не раз попадались такие проекты, от кода которых берет оторопь. Такое чувство, что сами авторы не смогут объяснить - почему у них все выглядит именно так. В этот момент у меня возникает вопрос: как так получилось? Если вас он тоже волнует, то могу пожелать лишь приятного чтения.

В минувшем году все только и говорили об ИИ и о том, как он может всё за вас сделать.

Мне нравится, когда кто-то или что-то работает за меня. Поэтому решил: попрошу-ка ChatGPT написать за меня новогодний пост:

«Эй, ChatGPT. А ты можешь реализовать большую языковую модель на SQL?»
«Нет, SQL не подходит для реализации больших языковых моделей. Язык SQL предназначен для выполнения запросов к данным, хранящимся в РСУБД и для управления этими запросами. Для реализации большой языковой модели требуются сложные алгоритмы, обширные датасеты, а зачастую — и фреймворки для глубокого обучения. SQL всеми этими возможностями не обладает.»

Что ж, лишний раз убеждаешься, что, если хочешь что‑то сделать хорошо – сделай это сам.

Давайте же воодушевимся этим оптимистическим планом и реализуем большую языковую модель на языке SQL.

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

Целью статьи является не освещение какой-то конкретной особенности языка или подготовка к собеседованиям, и уж тем более нет цели рассказать все потайные смыслы языка, т. к. для этого не хватит одной статьи и даже книги. Напротив, статья нужна для того, чтобы показать малоизвестные и странные решения, принятые в языках C и C++. Своего рода солянка из фактов. Вопрос “что делать с этими знаниями?” я оставляю читателю.

Если вы, как и я, любите и интересуетесь C/C++, и эти языки являются неотъемлемой частью вашей жизни, в том числе и его углубленного изучения, то эта статья для вас. По большей части я надеюсь, что эта статья сможет развлечь и заставить поработать головой. И если получится, рассказать что-то, чего вы, возможно, еще не знали.

Речь пойдет о способе извлечения данных с неисправного SSD для случаев когда после попытки чтения любого сбойного сектора - SSD совсем перестает отдавать данные и помогает только отключение включение питания.

Представляю доработанную версию скрипта ddrescue-loop с поддержкой управления USB реле и uhubctl.

Для прерывания питания SSD задействовал простое и дешевое решение USB Relay Module LCUS-1 CH340 которые доступны на Aliexpress. И подключение через док станцию AgeStar 31CBNV1C на основе USB-NVMe моста JMicron JMS583.

Рассмотрим процесс восстановления на примере случая с неисправными M.2 NVMe SSD производства Kimtigo на контроллере Maxio MAP1202.

Хотя уменьшение сегодня уже необязательно, оно всё равно лучше.

Новогодние подарки, выборы, долой OAuth 1.0, OSM в науке, QGIS и на бумаге, а также 700-ый выпуск weeklyOSM!

Если судить по группе ВК, дополнение вышло где-то 31 декабря в 7:38 минут по Москве. Новость дошла до меня где-то за час-два до нового года. Если вы в курсе, то думаю вы уже или без меня ознакомились или вот, прочитав новость, побежите прямо сейчас и статья для вас тут по сути заканчивается). Сначала Doom порадовал ... а сейчас Герои.

Если вы не в теме, то в остатке заметки попробую рассказать пару слов о том, почему: это дополнение важно, почему люди ждали его пять лет и почему это абсолютно уникальное явление для "игровой индустрии" (и да, там есть и кампания, и мультиплеерное обновление, и редактор карт новый, и музыка и новый замок).

Я с трудом удержал себя от того, чтобы не засесть на пару суток проходить кампанию залпом, но конце расскажу своё мнение про первые две карты (я специально не спешу). Итак, обо всём по порядку.

Введение

1. Ограничение пропускной способности. Поток по ребру не может быть больше его (ребра) пропускной способности.
2. Антисимметричность. Для каждого ребра (u, v): F(u, v) = -F(v, u).
3. Сохранение потока. Для каждой вершины (кроме S и T), количество входящего потока (отрицательного) равен количеству исходящего потока (положительного). Тоесть, алгебраическая сумма потоков для каждой вершины (кроме S и T) равна нулю.