Это началось со статьи «Алгебраические типы данных на самом деле не такие страшные». Мы знаем о типах‑суммах и типах‑произведениях. Но задумывались ли вы когда‑нибудь о том, откуда они получили такие имена, и как вообще были открыты они и их свойства? Я провел последнюю неделю в кроличьей норе истории, и я просто обязан поделиться тем, что я нашёл.
В первой части мы рассмотрели ключевые проблемы логического рассуждения в LLM и показали, в чём именно модели ошибаются.
Во второй части узнали, какие существуют методы решения LLM логических задач, а также посмотрели на их сильные и слабые стороны.
В этой – мы обсудим, как модели иногда идут вразрез с собственной логикой и что эксперты предпринимают, чтобы это исправить.
В первой части мы рассмотрели ключевые проблемы логического рассуждения в LLM и показали, в чём именно модели ошибаются.
В этой – мы обсудим методы, с помощью которых LLM решают логические задачи, включая внешние решатели, подсказки и обучение на логических примерах, а также их сильные и слабые стороны.
Тестирование — это не просто поиск ошибок. Это способ убедиться, что продукт действительно работает так, как должен, и делает жизнь пользователей проще, а не сложнее. Хорошее тестирование начинается задолго до первого нажатия кнопки “Run tests” — с понимания логики продукта, требований и рисков.
Как-то раз мы со студентами-переводчиками по ИТ задались вопросом:
А реально ли LLM «думает»? Или она просто, подобно школьнику, подгоняет объяснения под ответ в конце учебника, не имея ни малейшего понятия о том, правилен ли этот ответ или логичны ли ее рассуждения?
Поиски ответов на этот вопрос привели нас к статье-исследованию "Empowering LLMs with Logical Reasoning: A Comprehensive Survey", адаптированный перевод которой мы и предоставляем вашему вниманию.
Статья представляет собой большой обзор подходов к тому, как сделать языковые модели не просто «говорящими машинами», а системами, которые умеют думать, делать выводы и находить логические связи, «не натягивая сову на глобус».
Как часто, используя прокси для решения задач, вы задумывались о правильности выбора типа прокси? Как говориться, а туда ли я иду? Правильные ли со мной попутчики? Если вы не специалист, хотя бы среднего уровня, уверен - вы ответите: "Да, вообще никогда не задумывался, просто вбиваю "купить прокси" и беру самый дешевый вид". Вы не одиноки - так делают 80% пользователей. Самые дешевые - это как раз серверные прокси, использовать которые нужно с умом, чтобы не навредить проекту, над которым работаете. Давайте разбираться, что это за зверь и почему он может быть опасен?
Про OPC UA слышали мы все, кто хоть раз работал со SCADA системами, АСУ ТП или просто в студенческие годы пытался состыковать оборудование и программы верхнего уровня.
Обещают независимый, безопасный, масштабируемый, al inclusive стандарт для промышленного Интернета вещей. Но как это работает в реальных условиях? Что происходит, когда ты ставишь OPC UA-сервер не в демо-лаборатории, а в реальных условиях на производстве, где есть полный набор динозавров из 90х, 00х и современные монстры. И мы хотим, чтобы работало, не тормозило и все вместе.
В этой статье я попробую рассказать, как мы внедряли OPC UA в нескольких проектах, на практике, в реальных условиях со всеми плюсами и минусами.
Привет, Хабр! Меня зовут Павел Иванов, я работаю в AWS и последнее время выступаю ментором для наших стажёров и новичков.
– «А что пушить?» – «Всё по задаче». – «И тесты тоже?»
Этот короткий диалог когда-то ввёл меня в ступор на несколько секунд. После него я стал замечать: чем опытнее становишься, тем сложнее вспомнить, каково это – не знать тех вещей, которые со временем стали чем-то привычным и естественным. Для ментора это базовые рабочие рефлексы, а для стажёра – тайные знания, которыми никто не поделился. В итоге оба попадают в ловушку взаимного непонимания: один считает своё объяснение исчерпывающим, упуская десяток «очевидных» для него деталей и нюансов, а другой молча закапывается в проблему и, начав двигаться в неверном направлении, теряет ценное время.
В этой статье я собрал свой список таких навыков, и поделил их на две группы: неочевидные пробелы – слепые зоны для нас, менторов; и очевидные пробелы – то, чему можно и нужно научить новичка прямо сейчас, не дожидаясь, пока «само придёт с опытом».
Приветствую всех читателей! Меня зовут Игорь Конев и я техлид команды STaaS (Storage As A Service) в Авито. Сегодня я хотел бы в очередной раз поднять тему оценки задач, а конкретно оценки при помощи Story Points. Хотя мы давно применяем их в работе, оказалось, что команда по-разному трактует детали. Поэтому мы решили систематизировать и выровнять наши знания. Результатом работы стал этот материал, которым я с радостью делюсь с вами. Он не претендует на откровения, но удобно собирает терминологию, практические советы и наш опыт — возможно, это сэкономит вам пару-тройку Story Points.
Давайте разберем ППРФ № 1300 на молекулы, и разберемся, наконец, что-же там написано. Ниже таблица, в которой разобраны некоторые пункты данного постановления по-отдельности.
Сначала давайте определимся с терминами.
Через весь текст ППРФ речь идет про некое действие (процесс), который называется «передача», и осуществляется над объектом называемом «Информация об инициаторе телефонного вызова» это ни что иное, как «маркировка из 32 символов».
Для начала давайте отдельно разберем пункт 5 постановления, как самый трудночитаемый:
5. В целях передачи информации об инициаторе телефонного вызова на пользовательское оборудование (оконечное оборудование) оператор-инициатор предоставляет оператору связи, оказывающему услуги подвижной радиотелефонной связи, на основании договора об отображении информации, заключенного между инициатором телефонного вызова и оператором-инициатором, сведения, предусмотренные пунктом 6 настоящих Правил, в случае, если инициатор телефонного вызова самостоятельно или по запросу оператора-инициатора уведомил оператора-инициатора об отсутствии договора об отображении информации, заключенного ранее между инициатором телефонного вызова и оператором связи, оказывающим услуги подвижной радиотелефонной связи.
Около года назад я написал первую часть статьи о Single SPA — о том, как я выбирал архитектурный подход, боролся с монолитом и пробовал собрать первые микрофронтенды. В статье были разобраны базовые принципы работы Single SPA, подключение importmap, сравнение с другими архитектурными решениями и настройка сборки на Webpack и Vite.
Эта статья — продолжение цикла. Здесь я поделюсь практикой: как на самом деле живётся с Single SPA, какие есть подводные камни и что можно вынести в виде рекомендаций.
Сразу скажу: Single SPA — не «серебряная пуля» и уж точно не современный тренд фронтенд-разработки. В 2025-м появилось еще больше других подходов, которые решают похожие задачи иначе. Но Single SPA всё ещё актуален там, где есть огромные легаси-системы, которые невозможно переписать с нуля. И вот именно для таких кейсов мой опыт может быть полезен.
Древнее и сакраментальное RTFM преследует нас повсюду. Волей-неволей мы вынуждены постоянно читать инструкции: к технике, приборам, приложениям, системам.
К сожалению, интерфейсы тех решений, которыми нам приходится пользоваться, далеки от идеала. Они не только не помогают нам решать важные задачи, но и зачастую всячески мешают пониманию смысла и содержания отдельных элементов.
В статье расскажу о пяти важных блоках информации, которые обязательно должно содержать руководство пользователя (оно же User Guide).
Привет Хабр! Меня зовут Алексей и я занимаюсь беспроводными технологиями. Сегодня разберем чем повторитель wi-fi сигнала отличается от wi-fi mesh. Многие на практике не различают эти понятия и часто считают что речь идет об одном и том же.
Беспроводные сети стали неотъемлемой частью нашей жизни, но зачастую одного роутера недостаточно для качественного покрытия большого дома или офиса. В поисках решения мы сталкиваемся с двумя основными подходами: WiFi mesh системы и ретрансляторы (repeater). Несмотря на схожую цель — расширение зоны покрытия — эти технологии кардинально отличаются по принципу работы, производительности и применению.
Сколько раз уже писано-переписано о том, что современные печатные книги на компьютерную тематику — это на редкость некачественный товар. И всё равно каждый раз я не перестаю удивляться, как же их создатели не стыдятся выпускать, да ещё и продавать за деньги такой редкостный треш.
И дело даже не в кривом переводе. Мы уже давно научились догадываться, что именно «хотел сказать автор» на языке оригинала. Этот этап повсеместного падения качества книг уже пройден. Теперь издательства нацелились на новые антирекорды — соревнуются, кто кого переплюнет по количеству фактических ошибок в своих творениях. Например, по ужасающим косякам в исходных кодах примеров программ. Каждый раз хочется воскликнуть: «Ребята, вы сами-то хоть один раз перечитали своё творение?!»
Во всём виноваты маркетологи, естественно! Но на самом деле нет: я бы сказал «Раньше надо было думать!», да за такое и закэнселлить на Хабре могут.
С проблемой терминологии сталкивается каждый технический писатель. Многие ИТ-термины заимствованы из английского языка и имеют несколько вариантов перевода, или не переводятся вовсе. Для создания терминологии необходимо проанализировать существующие термины и их использование, выбрать единый стандарт написания и сделать термины понятными для всех членов команды.
Мы — команда документирования платформы Platform V в СберТехе: Лидия Ковач, middle технический писатель, Мария Бурханова, senior технический писатель, и Светлана Каюшина, руководитель команды. Хотим рассказать, как мы разработали глоссарий, который повысил качество документации нашей цифровой платформы для построения ИТ‑ландшафта.
Поделимся тем, как устроен наш глоссарий, с какими трудностями мы столкнулись и какими инструментами пользовались. Надеемся, это поможет вам добиться точности и единообразия терминологии в вашей компании.
Продуктовые роли не появились из воздуха. Их не придумали с нуля бородатые дядьки в Долине или выглаженные воротнички из Купертино. Профессии Product/Project Owner/Manager выстраивались на протяжении почти столетия — и всё ради того, чтобы сейчас мы с вами плевались, читая вакансии на хедхантере. Кто главнее: PM или PO? Что должен делать проджект? И что ещё за AI PM и Data PM?
Давайте разбираться. И копнём аж до начала прошлого века.
На днях обнаружил, что в русскоязычной сети нет перевода этой раритетной статьи, которая положила начало разработке самого известного архитектурного паттерна MVC. Восполняем пробел.
Содержание этого документа интересно и с исторической точки зрения (а как там “деды” воевали программировали), так и в плане уточнения некоторых современных представлений об этом паттерне и программной архитектуре в целом.
Иллюстрации по максимуму сохранены как в оригинале. По ходу есть сноски с подробностями и ассоциации редактора в конце.
СУЩНОСТЬ-МОДЕЛЬ-ВЬЮ1-РЕДАКТОР
на примере из системы планирования2
Кому: LRG3
От: Тригве Реенскауг4
Файл: [IVY]<Reenskaug>SMALL>TERMINOLOGY2.DOC
Дата: 12 мая 19795
Цель данной заметки - исследовать метафоры thing-model-view-editor через последовательный набор примеров. Все примеры взяты из моей системы планирования и иллюстрируют вышеуказанные четыре понятия. Все примеры были реализованы, хотя и не в рамках чистой структуры классов, описанной здесь. Метафоры соответствуют real world-Model-view-Tool, предложенным в заметке о требованиях DynaBook ([Ivy]<Reenskaug>DynaBook.doc).
THING (СУЩНОСТЬ)
ОПИСАНИЕ ТЕРМИНА
Нечто, представляющее интерес для пользователя. Это может быть что-то конкретное, как дом или интегральная схема. Это может быть что-то абстрактное, как новая идея или мнения о статье. Это может быть целое, как компьютер, или часть, как элемент схемы.
ПРИМЕР: КРУПНЫЙ ПРОЕКТ
Сущность здесь - это крупный проект. Это может быть проектирование и строительство большого моста, электростанции или морской нефтедобывающей платформы.
Почему в 2025 мы все еще используем CLI? Вокруг так много прекрасных pixel-perfect GUI на OLED-экранах, а интернет провели даже в часы, очки и кольца. Как проектировщик взаимодействия с серверной ОС я часто участвую в дискуссиях на тему «GUI vs CLI». Это вдохновило меня поисследовать, почему CLI такой, какой есть, что подарила ему современность и почему GUI до сих пор не заменил его на серверах.
Благодаря (в том числе) статье на Хабре от 2010 года в 2011-2012 гг. плотно изучал, что такое блокчейн и криптовалюта.
И, если сначала многие считали это гиковским изобретением, некой вещью-в-себе, то позже большая четвёрка решила родить мысль о том, что криптовалюта - скам, а вот блокчейн - важное изобретение человечества (но, как заметил С. Возняк, всё ровно наоборот, хотя и он был не прав); после этого, в криптозиму 2018-го посыпались утверждения о том, что блокчейн вообще никому и нигде не нужен; в 2020-х риторика сменилась на то, что блокчейн нужен, но не везде и, наконец, сейчас блокчейны настолько разнообразны, как по скорости (масштабированию), так и по безопасности, и децентрализации, что их можно применять везде и внедряют их повсюду: от учёта права собственности (в Грузии) и планирования бюджета (в США) - до токенизации всего и вся (RWA, DePin, etc.).
И тем не менее у блокчейна и криптовалют, благодаря мифологии, навязанной СМИ, всё ещё много противников и критиков.
Они никак не хотят признавать один важный и очевидный факт: чтобы человечеству рвануть вперёд, к цивилизации I-II-III типа, надо… стать человечеством именно, т.е. единым, планетарным видом. Для этого в свою очередь необходимо решить 4 фундаментальные проблемы:
