Просто знать 15 важных паттернов, которые помогут облегчить тернистый путь в решении алгоритмических задач. Про эти паттерны мы и расскажем в этой статье.
Просто знать 15 важных паттернов, которые помогут облегчить тернистый путь в решении алгоритмических задач. Про эти паттерны мы и расскажем в этой статье.
LLM - мощный инструмент, но его эффективность в продакшене зависит не от одного «хитрого промпта», а от всей архитектуры: что мы даём модели, как управляем её рассуждением и как проверяем/обрабатываем результат. В этой статье - компактная карта паттернов, разбитая по этапам конвейера: Input -> Reasoning -> Output.
Статей про LLM - вагон, и у всех свои "трюки". Мне не хватало схемы, которая раскладывала бы эти "трюки" по полочкам.
Когда мы говорим о сознании, особенно в контексте искусственного интеллекта, нас неизбежно настигает «трудная проблема сознания» (ТПС), сформированная Дэвидом Чалмерсом: почему и как из физических процессов в мозге возникает субъективный опыт (или квалиа) — ощущение красного, вкус хруста булки, мурашки от музыки?
Этот вопрос стал мемом, философским барьером и вызовом для проектирования искусственного интеллекта который, похоже, невозможно преодолеть.
При решении этой проблемы философы и специалисты по когнитивным наукам застряли в трёх тупиках:
Многие из нас слышали про лучшие практики в программировании (KISS, DRY, SOLID, паттерны и прочее). У начинавшего разработчика при их изучении встает немой вопрос «а зачем мне все это?». Ответом на вопрос может послужить знаменитая в узких кругах игра «Щи» и статья автора, рассказывающая о процессе разработки. Однако оригинальный пост уже давно утерян в просторах интернета.
Доброго времени суток!
Для начала представлюсь: я бэкенд-разработчик с опытом более 8 лет. Участвовал в разнообразных проектах: в стартапах, в галерах, в крупных корпорациях и в среднем бизнесе. К сожалению, найти идеальную статистику по данной теме не представляется возможным, однако из общения с бывшими коллегами я понимаю, что то, что будет описано ниже, — не только мой личный опыт, но и то, что регулярно происходит в других компаниях.
С тех пор, как микросервисы захватили умы и серверные стойки, одна тема всплывает с завидной регулярностью. От финтеха, где цена ошибки – реальные деньги, до гигантов e-commerce с их бешеными нагрузками – везде одно и то же: как подружить данные, разбросанные по десяткам независимых сервисов? Старые добрые ACID-транзакции, наша палочка-выручалочка из монолитного прошлого, в новом распределенном мире часто не просто не работают, а ломают всё – доступность, независимость, саму идею микросервисов. Сегодня хочу поговорить начистоту об одном из мощнейших, хотя и непростых, инструментов в нашем арсенале – паттерне Saga.
Идиома RAII — давно зарекомендовал себя как удобный способ автоматического управления ресурсами в C++. Обычно мы применяем его для управления памятью, файловыми дескрипторами или мьютексами. Однако что, если расширить понятие RAII до управления не только физическими ресурсами, но и логическими контрактами и состояниями системы?
В этой статье я хочу поговорить о том, как RAII можно использовать для контроля жизненного цикла асинхронных операций, транзакций или подписок, гарантируя их корректное завершение или откат до прежнего состояния.
При переходе от монолитной к микросервисной архитектуре разработчики часто сталкиваются с несколькими проблемами.
Во-первых, это необходимость переработки существующего кода и его разбиения на независимые сервисы, что может быть трудоемким и сложным процессом.
Во-вторых, возникают сложности с обеспечением взаимодействия между микросервисами, включая управление сетевыми запросами и обработку ошибок. Кроме того, важно наладить мониторинг и логирование каждого микросервиса для своевременного выявления и устранения проблем в распределенной системе.
Использование в практике таких паттернов как Читать полностью »
Недавно столкнулся с такой проблемой, что не всегда приходиться выполнять defer вызов функции. Те кто знают, как работает defer можете листать вниз до реализации моего паттерна.
Представьте, что у вас есть 10 кейсов, в одном из которых не вам не нужен вызов defer func. Что же тогда делать......
Оператор defer помещает вызов функции в список. Список сохраненных вызовов выполняется после того, как возвращается функция. Defer обычно используется для упрощения функций, выполняющих различные действия по очистке.
package main
import "fmt"
func foo(){
defer fmt.Println("Deffered out")
fmt.Println("End of func")
}
func main(){
foo()
}
Результат:
End of func
Читать полностью »
Когда я только знакомился с принципами SOLID, я искал понятные статьи на Хабр. При этом пришлось прочитать не одну статью, и полное понимание пришло сильно позже. Хотелось бы, чтобы новички на более простых примерах смогли почувствовать, о чем эти принципы:
При написании кода программисту следует руководствоваться определенными правилами. Часто эти правила написаны если не кровью, то слезами разработчиков, которые потом стараются исправить ваш код. Если это вообще возможно :)
Принципы S.O.L.I.D.Читать полностью »