Каждый C#-разработчик хотя бы раз писал что-то вроде:
var result = numbers.Where(x => x > 10).Select(x => x * 2).Take(5);И почти каждый на старте карьеры удивлялся, узнав, что эта строчка ничего не вычисляет. Ни один элемент коллекции ещё не тронут, ни один предикат не вызван — вся цепочка спит. Вычисления начнутся только тогда, когда мы начнём перебирать result в foreach или вызовем .ToList().
Привет!)
Периодически хочется почитать книги с ноутбука, особенно в дороге. Но у «Яндекс Книг» есть только мобильные приложения и сайт, а отдельного клиента для Windows нет. Через браузер читать можно, пока есть нормальный интернет, однако в поезде или за городом этот план иногда заканчивается одновременно с мобильной сетью.
Можно было скачать книгу где-нибудь ещё, поставить обычную EPUB-читалку и не усложнять себе жизнь. Но библиотека и подписка у меня уже находились в одном сервисе. Поэтому я выбрал более логичный для программиста вариант: решил самостоятельно написать неофициальный десктоп-клиент.
На предыдущей работе был простой подход: используем любые ИИ‑инструменты — главное результат. Что приводило к тому, что разработчик не мог внятно объяснить, для чего это написано. Главное, что тесты проходят? А то, что находится в чёрном ящике — дело второстепенное.
На текущей работе к ИИ отношение осторожное. По моим наблюдениям многие используют как чат, а не как агент. Есть определенные модули, которые не должны утечь. Мне стало интересно разобраться насколько можно автоматизировать генерацию кода.
Я вижу четыре основных варианта использования ИИ в разработке:
Современные компьютеры используют так называемые псевдослучайные генераторы чисел (PRNG — Pseudorandom Number Generator). Эти алгоритмы создают последовательность чисел, которые кажутся случайными, хотя на самом деле они вычисляются на основе определенной формулы и начального значения — «семени». При этом «семя» может быть абсолютно любое, начиная от времени на компьютере, заканчивая шумом от молний (например, так работает сайт https://www.random.org).
Пятница, 23:47. PagerDuty: “Платёж AmEx, провайдер вернул 5xx три раза подряд, билеты не зарезервированы.” Открываю логи – действительно 3 ответа провайдера с 5xx, ни одной успешной транзакции по нашей базе. Закрываю как временный сбой на стороне провайдера, пишу короткую сводку в дежурный чат и иду досматривать. Через 40 минут второй алерт – уже от ночной поддержки: клиент прислал скрин выписки, 3 списания подряд за одну бронь. У клиента рейс через 6 часов, ему нужна действующая бронь и подтверждение, что он завтра нормально улетит, а не тикет в поддержку.
Примечание переводчика:
State Machine, конечный автомат это преобразованный async метод. Компилятор преобразует метод в тип, реализующий конечный автомат (наследуется от IAsyncStateMachine). Благодаря такому механизму, при достижении первого оператора await поток, начавший метод, может возвращаться без «физического» оператора return метода, тем самым, продолжая выполнение основной программы.
В математике, конечный автомат это некоторая система, которая может находится только в одном состоянии.
(Возможные) состояния конечного автомата:
Ты только что получил задачу перенести сервис на gRPC - и думаешь, что это просто «взял protobuf, описал контракты, запустил кодогенерацию«? Так думал и я. До тех пор, пока не столкнулся с тем, что decimal в protobuf попросту не существует, nullable int превращается в нечто с флагом HasValue вместо привычного int?, а два enum в одном файле могут убить сборку из‑за конфликта имён значений — и компилятор скажет тебе об этом совсем не очевидно.»
