Развитие LLM значительно изменило процесс разработки ПО. Однако, если присмотреться к тому, как разработчики на самом деле используют эти инструменты, картина оказывается весьма разнообразной. Одни применяют ИИ как продвинутое автодополнение, другие ожидают, что он создаст целое приложение по одному промпту.

Чтобы систематизировать подходы к ИИ-программированию, воспользуемся простой моделью. Вместо того чтобы воспринимать "кодинг с ИИ" как единый монолитный процесс, мы можем отобразить его на матрице 2×2, основанной на двух ключевых осях:

Вовлеченность человека в код: Пишете ли вы код вручную (читаете, редактируете и проводите код-ревью) или работа с ним полностью делегирована LLM.

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

Кодинг-агенты умеют быстро генерировать код, но результат часто расходится с ожиданиями. Естественный язык слишком неоднозначен для передачи точных требований, а классические unit-тесты с десятками ассертов тяжело читаемы.

Хороший подход для работы с агентами базируется на принципах BDD (Behavior-Driven Development). Нам важно не то, как реализована задача, а как ведет себя система. Лучший способ передать это поведение машине и легко проверить человеку - исполняемые спецификации.

При первом запуске агент не знает структуру проекта. Из-за этого возникают проблемы:

Читает слишком много файлов и быстро расходует контекст.

Или, наоборот, не находит нужные файлы и места в коде.

Управление состоянием — одна из важнейших задач, решаемых в разработке на React. Было создано множество инструментов в помощь разработчикам для решения этой задачи. Наиболее популярным инструментом является Redux — небольшая библиотека, созданная Дэном Абрамовым, и предназначенная помочь разработчикам использовать паттерн проектирования Flux в их приложениях. В этой статье мы разберем, действительно ли нам нужен Redux, и посмотрим, как мы можем заменить его более простым подходом, в основе которого лежат Observable и React Hooks.

"Вы поймете, когда вам нужен Flux. Если вы не уверены, что вам это нужно, вам это не нужно." Пит Хант

Для управления состоянием приложения я как правило применяю Redux. Но не всегда есть необходимость в использовании модели Action\Reducer, хотя бы из-за трудозатратности ее применения для написания простейшего функционала. Возьмем в качестве примера обычный счетчик. На выходе хотелось получить простое и практичное решение, которое позволит описать модель состояния и пару методов его меняющие, наподобие такого:

state = {value: 0} 
increase() { 
  state.value += 1 
} 
decrease() {
  state.value -= 1
}

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

В общем, захотелось найти простое решение для управления состоянием, в основе которого лежала бы иммутабельность, с возможностью применять его в Angular\React и реализованное на TypeScript. Беглый обзор на просторах github подходящего решения не выдал, поэтому возьмем RxJS/Immer и попробуем сделать свое.

Мы как программисты иногда попадаем в "программистский ад", место где наши обычные абстракции не справляются с решением ряда повторяющихся проблем.

В данной статье будут рассмотрены такие проблемы, синтаксические конструкции используемые для их решения и наконец как эти проблемы могут быть решены единообразно с помощью монад.

Ад проверки на null

Данная проблема возникает когда несколько частичных функций (функции которые могут не вернуть значение) нужно выполнить последовательно.

Такие функции обычно приводят в глубоко вложенному и сложно читаемому коду с чрезмерным количеством синтаксического шума.

var a = getData();
if (a != null) {
  var b = getMoreData(a);
  if (b != null) {
     var c = getMoreData(b);
     if (c != null) {
        var d = getEvenMoreData(a, c)
        if (d != null) {
          print(d);
        }
     }
  }
}

В статье попытаюсь рассказать об опыте поиска кроссплатформенной технологии для реализации хобби проекта посвященного тренировке мозга и некоторых приемах ее геймификации.

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

И пока идея полностью не созрела, начался процесс поиска технологий для реализации версии сайта 2.0, плюс был интерес по изучать новые технологий и языки

Творческое мышление

• Что есть монада на примере Maybe.
• Что такое CPS и монада продолжения.
• Как это связать с классом Task из TPL.

$("<div>", {"class":"something",id:10})