В прошлой части я говорил про адаптацию API Godot к F#. Далее в планах было разобраться с общей структурой приложения, но я столкнулся с необходимостью закрыть серьёзный пробел в публичном корпусе текстов. Так что в этой и последующих частях я буду объяснять нечто странное — как из обычной функции путём эволюции получается работающая программа на Godot.

На мой взгляд, у большинства F#-новичков тактический и стратегический уровень находятся в разных вселенных. Типа вот здесь в локальном пространстве у нас ФП, а на глобальном внезапно тащит только ООП. Это, конечно, хорошо, что мы можем склеивать две парадигмы, но мне кажется, что эта непреодолимая стена на границе сферы деятельности ФП не такая уж непреодолимая. Существование её обусловлено не объективными причинами, а недостатком опыта.

Вечер. Пересматриваю «Пятницу 13». Не люблю пересматривать фильмы, даже хорошие. Но выбрать интересное кино из потока новинок сложно. Поэтому мне захотелось написать свой рекомендатор кино. Этим и займусь в выходные. 

В статье покажу, что получилось написать за 2 дня. Писал всё «на коленке» по доступным библиотекам и данным. Получилcя DIY-рецепт. Всё платформозависимое работает в Docker, чтобы повторить и развернуть можно было везде. 

Многие онлайн-сервисы предлагают доступ к проприетарным LLM. Однако по различным причинам может возникнуть необходимость использовать эти модели на своем оборудовании. Аренда серверов, особенно с GPU, может быть дорогой и зависит от требований к RAM/VRAM. Квантование моделей помогает снизить эти требования.

Когда создаешь новое приложение, особенно если оно должно быстро обрабатывать данные, использование библиотеки asyncio — это хороший выбор. Она позволяет работать с неблокирующими библиотеками, asyncpg и aiohttp. Однако чаще всего программисты работают с уже существующим кодом, который использует блокирующие библиотеки. Поэтому большую часть времени может занять адаптация и модернизация старого кода, так как асинхронный код не дружит с синхронным (им мешает GIL).

GIL (Global Interpreter Lock) — это механизм, который предотвращает одновременное выполнение нескольких потоков в Python. Это означает, что даже если у вас есть многопоточное приложение, только один поток может выполнять Python-код в любой момент времени. Поэтому можно запускать дополнительный поток для выполнения операции ввода-вывода.

В прошлый раз я в основном говорил о трудностях, которые возникают при попытках совместить F# и Godot. Это была вынужденная мера, так как нас в первую очередь интересовало «стандартное» поведение на случай, когда нестандартное и удобное почему-то не сработало. Можно сказать, что мы учились падать без серьёзных последствий перед тем, как научимся совершать броски и болевые приёмы. Нужный ход, если мы не хотим за пару занятий инвалидизировать большую часть группы, но всё-таки это не то, за чем мы пришли в секцию. Теперь пришло время перейти к рутине, а за ней — и к более агрессивным техникам.

В 1952 году компания IBM, уже тогда известная своими новаторскими решениями в сфере вычислительной техники, представила миру свой первый электронный компьютер – IBM 701. Его появление стало началом нового этапа – эры цифровых технологий. Об IBM 701 мы упоминали в материале «История IBM: От табуляторов до суперкомпьютеров». В этой статье погрузимся в историю создания этого устройства и расскажем, что же сделало IBM 701 столь значимым.

IT-индустрия совершила интересный виток развития в последние десятилетия. На заре IT-революции, когда компьютеры были дорогими, их ресурсы, хоть и скромные по нынешним временам, нужно было использовать эффективно. Это привело к появлению многопользовательских OS, например, семейства UNIX, созданию компьютерных сетей и появлению протоколов удаленного доступа. 

Стремительное развитие производительности чипов и удешевление железа привело к революции персональных компьютеров. Однако опережающий рост вычислительных потребностей запустил развитие на новый круг. Сейчас найдется немного компаний и организаций, которые обходятся исключительно персональными компьютерами и сервисами в локальной сети. Когда-то диковинные IaaS, PaaS, SaaS, распределенные вычислительные технологии плотно вошли в жизнь. Доступ к удаленным системам — обыденная потребность не только для администраторов и программистов. Все знают о протоколах ssh, rdp, vnc, многие пользуются TeamViewer, AnyDesk, Remmina, X2Go и т. п. Ввиду того, что IPv4 сети и порожденный ими NAT пока еще более чем актуальны, не каждое из перечисленных средств позволяет подключиться к машине, находящейся за NAT, если у вас нет возможности пробросить порты.

Язык программирования Swift наиболее широко применяется в разработке программного обеспечения для операционных систем от компании Apple. Но не так давно появилась заметка, в которой говорится, что теперь на этом языке можно писать программы, основанные на GTK4+Libadwaita.

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

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

Представьте, что у вас есть друг, который дает разные ответы на один и тот же вопрос в зависимости от того, как вы его задали. «Какая столица Перу?» получит один ответ, а «Лима — столица Перу?» — другой. Вы, вероятно, немного обеспокоены умственными способностями вашего друга, и вам почти наверняка будет трудно доверять его ответам. 

Именно это и происходит со многими большими языковыми моделями (LLM), сверхмощными инструментами машинного обучения, которые поддерживают ChatGPT и другие чудеса искусственного интеллекта. Генеративный вопрос, который является открытым, дает один ответ, а дискриминативный вопрос, который подразумевает необходимость выбора между вариантами, часто дает другой. «Происходит разрыв, когда один и тот же вопрос формулируется по-разному», — сказал Атул Пол Джейкоб, докторант Массачусетского технологического института.

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

Для демонстрации будем использовать модели caffe и onnx. Сервис напишем с использованием golang. Ниже приведен пример изображения, на котором распознан пол и примерный возраст человека. В нашем сервисе мы будем возвращать JSON, в котором будут указаны возраст, эмоции, пол и местоположение лиц на фотографии.

Все сталкивались с ситуацией, когда нужно было объяснять что-то другому человеку — будь то коллега, ребенок, друг или родственник. Иногда это происходит легко и непринужденно, а иногда… превращается в настоящую пытку. Особенно когда человек, которому мы объясняем, никак не может «включиться» и понять. 

 В такие моменты мы начинаем думать: «Как это можно не понять? Это же элементарно!» или «Он просто прикидывается, чтобы я сделал его работу!». Но, скорее всего, истина лежит гораздо глубже. Мы забываем, что когда-то и сами этого не знали. И в этом замешано проклятие знания.

Проклятие знания — ошибка мышления, из-за которой мы предполагаем, что другие люди обладают теми же знаниями, что и мы.

Когда человек владеет определенной информацией, зачастую ему трудно представить, каково было бы не знать ее. Для него это элементарно. Он не понимает позицию другого, и это значительно усложняет общение. 

В этой статье попробуем разобраться в том, как проклятие знания влияет на разработку и как избежать его негативных последствий.

В прошлой части мы проецировали внешние контракты в DTO на примере REST. В этой будем проецировать методы контрактов в нечто, что позволит вызывать их вот так:

let! issues = gitflic.project.["kleidemos"].["myFirstProject"].issue.GET(limit = 24)

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

Оптические нейронные сети, использующие фотоны вместо электронов, имеют преимущества перед традиционными системами. Но они также сталкиваются и с серьезными препятствиями.

Закон Мура уже работает весьма быстро. Он утверждает, что примерно каждые два года число транзисторов в компьютерных чипах увеличивается в два раза, и это приводит к значительному скачку скорости и эффективности. Но потребности в вычислениях в эпоху глубокого обучения растут ещё быстрее — темпами, которые, вероятно, могут меняться. Международное энергетическое агентство прогнозирует, что в 2026 году искусственный интеллект будет потреблять в 10 раз больше энергии, чем в 2023 году, и что центры обработки данных в этом году будут потреблять столько же энергии, сколько вся Япония.

Число судебных разбирательств по поводу нарушения интеллектуального права постоянно растет. Только за последний год оно увеличилось на 21%. При этом определенная часть дел связана именно с нарушениями закона информационными посредниками, которыми могут быть владельцы сайтов, маркетплейсов, хостинг-провайдеры и др. Достаточно разрешить пользователю загружать или делиться контентом, защищенным авторским правом, и вот ты уже нарушил закон. 

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

В данном цикле я хочу поговорить об одном из вариантов представления REST-клиента. Но я буду обсуждать частное (REST), чтобы использовать его как точку опоры для перехода к общему — проблеме проекций внешних контрактов. В первых двух частях я сосредоточусь на синтаксисе и «архитектурных» ходах, а потом поговорю о генераторах кода. Сложность будет расти с каждой частью, но предлагаемые подходы даже в рамках одной части можно применять независимо. Например, сейчас мы поговорим про DTO (Data Transfer Object), в следующий раз — про перенос методов и их иерархии. Это близкие модули, но их взаимное влияние осознанно будет сведено к минимуму.

Ранее я накатал большой цикл по локальному F#-кодогену и высказал намерение периодически возвращаться к генераторам на примере каких-то узконаправленных задачек. Данный цикл — пробный шар в этом направлении. Он логически вытекает из последних двух частей цикла, так что осилившие «Большой код» смогут посмотреть на уже знакомые концепции немного под другим углом.

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

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

Возьмем, к примеру, умножение матриц или массивов чисел. В 1812 году французский математик Жак Филипп Мари Бине разработал базовый набор правил, которым мы до сих пор обучаем студентов. Это работает прекрасно, но другие математики нашли способы упростить и ускорить процесс умножения матриц.

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

В конце прошлого года технологический гигант IBM объявил о том, что может показаться важной вехой в квантовых вычислениях: о первом в мире чипе под названием Condor, содержащем более 1000 квантовых битов или кубитов. Прошло всего два года после того, как компания представила Eagle, первый чип с более чем 100 кубитами. Казалось, что эта область стремительно движется вперёд. Создание квантовых компьютеров, способных решать полезные задачи за рамками даже самых мощных классических суперкомпьютеров, требует ещё большего их масштабирования — возможно, до многих десятков или сотен тысяч кубитов. Но это ведь всего лишь вопрос техники, верно?

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

Когда RAM близка к заполнению, данные неактивных в данный момент приложений начинают выгружаться из неё на диск, в файл или раздел подкачки. Когда при запуске ещё одного приложения, открытии файла или вкладки браузера, потребуется срочно освободить нужный для этого действия объём оперативной памяти, пауза в работе компьютера может быть заметна, даже когда в системе стоит SSD. На HDD же, в случае запуска ресурсоёмкого приложения, подкачка может приостановить работу и на несколько десятков секунд. Кроме того, постоянная подкачка на SSD приводит к его ускоренному износу, что с учётом цены SSD, также не лучшее решение.

Если типовые задачи вашего компьютера требуют в 2-3 раза больше оперативной памяти, чем стоит в системе, наилучшим решением будет её увеличение. Если установить больше памяти невозможно технически (самый, пожалуй, острый пример — нетбуки на процессоре Atom с максимально возможным объёмом RAM 2 Гб) — ресурсоёмкие задачи лучше перенести на более мощный аппарат, а этот использовать только для офисно-браузерных задач (отдать детям или родителям). В случае же менее значительной нехватки (в пределах половины имеющегося объёма RAM), есть возможность улучшить ситуацию.

В этой статье мы напишем небольшой сервис аутентификации на go с использованием токенов PASETO. Этот токен можно использовать вместо JWT для процесса аутентификации. Если хотите узнать о PASETO подробнее, то можете почитать статьи на Хабре или гитхабе.

Godot — игровой движок, который имеет нативную поддержку dotnet. К сожалению, эта поддержка до такой степени заточена под C#, что F# она выходит боком. Почти все проблемы разрешимы, но при недостатке опыта они скатываются в большой пластилиново-волосатый валик у самого входа в подземелье, который иногда приводит к преждевременной и бессмысленной гибели. Чтобы избежать этого в данной статье я дам программу-минимум, которая позволит выжить в Godot, но не выжать из него максимум.

Это не значит, что у сочетания F# + Godot нет своих плюшек. Просто мне хотелось съесть вначале сосредоточить всех мух в одном месте, а котлетами заняться потом и в более свободной манере. Также я предполагаю, что на данную статью будут натыкаться как новички в F#, так и новички в Godot, поэтому местами я буду дублировать базовые руководства.