让AI为孩子写童话故事
AI 技术的大力发展下,很多支持辅助写作的大模型如雨后春笋般出现。
AI 技术的大力发展下,很多支持辅助写作的大模型如雨后春笋般出现。
2024年5月,朋友 @东方赞 得到了一批显卡,搭建了多套大模型,为了解决模型应用问题,他调研了当时比较火的一些应用,并重点使用和分析了 Sider AI
和 ChatBox
。
最后得出结论,目前没有一个应用能很好的满足:既能对接大模型,又能自定义模型提示词,还能流程化地解决问题。于是我们展望了一下这个需求,梳理出一个核心特性:让多个 AI 模型群聊,流程化、通力解决问题。
在 Micronaut 项目中,使用了 Logback 输出日志。在添加了RollingFileAppender 后,编译 Native Image 就会报错了。
反复搜索后,发现问题原因是:编译 Native Image 也会使用 logback 进行日志输出,这个时候就会打开日志文件句柄,然后编译器发现有文件句柄被打开了,编译就被中止了。
按 GitHub 上大佬的建议,解决文案是定义一个延迟加载的 FileAppender。
当我们不论使用 Micronaut 框架还是其他框架时,如果项目中使用了 AWT 相应特性(仅特性,非 Swing 应用),比如生成图片,在我们 将 Java 应用编译为 Native Image 本地应用后,可能就会报出很多和 AWT 相关的异常,导致生成图片相关功能无法使用。
Quarkus 框架给出了官方的解决方案,直接按官方方案使用插件和制作基础镜像即可。
本文将给出一个 Micornaut 框架的完整的指南和项目示例,说明如何配置可以正确正确编译出支持 AWT 特性的项目。
甲辰龙年基本已经过去,等到正月十年元宵节过后,春节就正式结束了。
在过去的一年里,各行各业都遇到了很多瓶颈。身在软件研发行业中,能感受到更多的飘摇。新的一年,我们要怎么做呢?
本文翻译自 How To Implement Synchronous Interactions Between Microservices,原作者:OLEKSII
Micronaut 的英文名字由两部分拼接而成,“micro” 是“微小”,代表微服务,“naut”是船,代表的是载体。两部分的字面意思合并起来,可以理解为微服务的载体、微服务的运载之船。
上一篇中,我们概览一下 pig 项目的整体结构,并将其运行起来了。本篇我们进 一步分析一下各子项目。
在之前的示例中,我们直接对接 pac4j,并让项目运行起来了。在 Pac4jConfig
中,我们最先的配置的即是客户端 Client。
GitHubClient gitHubClient = new GitHubClient("a85f19ea0f51face127a", "84bf0695ea2a62674b8d5961a02a4c793bf23e2a");
GiteeClient giteeClient = new GiteeClient("da28980047eb2c732b8bcee4be567c6a4f38c6459587063f2607084c9c33b957",
"4cd81eac1dae28b698044ed5b55e2580da94aca7d872e11e5b47d6c8a3b0a26d");
我们常见的认证协议,包括 OAuth
、SAML
、CAS
和 OpenID Connect
等。在这些协议中,OAuth
协议只定义了基本的协议架构,但没有明确要求 API 如何指定,因而针对不同的协议提供厂商,需要开发不同的客户端进行对接。这些客户端最大的差异在于用户 API 响应的数据定义千差万别,所以自定义客户端最主要的实现是对用户数据的解析。
本篇我们以对接 Gitee 的 OAuth2.0 为例,实现自定义客户端。
我们以对接 GitHub
进行实战,能从项目指定路径 /login/github
跳转 GitHub
认证后,获取登录用户的相关信息在界面展示,其他 API 配置为不受此认证限定。
一个好的软件,需要一个好的文档,一个好的文档,需要一个好的工具。工欲善其事,必先利其器。
在我们写文档之前,选择一个好的工具,将会使用我们的工作事半工倍。
你的产品有多好并不重要,因为如果它的文档不好,人们就不会使用它。即使他们因为别无选择而不得不使用它,如果没有好的文档,他们也不会有效地使用它或按你希望的方式做。
几乎每个人都明白这一点。几乎每个人都知道他们需要好的文档,大多数人都试图创建好的文档。但大多数人都失败了。
pac4j 是一个简单而强大的安全框架,用于 Java 验证用户、获取用户配置文件和管理授权,以保护 web 应用程序和 web服务。
它提供了一套全面的概念和组件。它适用于大多数框架/工具,并支持大多数认证和授权机制。它的开源授权协议为 Apache 2。
在上一系列,对 RuoYi(若依)的单体项目比较简单地进行了探秘。虽然 RuoYi 的单体项目有很多不足,但是瑕不掩瑜,RuoYi 还是一个在小项目、验证项目、紧急项目时,可用的基础框架项目。本系列将会品鉴一个更有意思的项目:pig
。
在上篇中,我们基本对 RuoYi 最重要的菜单相关进行探究,其他业务的代码不再进行探究。本篇将从第三视角,使用第三方代码扫描工具等,对 RuoYi 项目的代码进行品评。
上篇中,我们对 Shiro 框架做一个简单的扩展了解,稍微了解了一些 Shiro 的概念及运行逻辑,然后我们发现了在用户登录成功后,RuoYi 对用户授予了角色和菜单,这两个数据是如何来的,又是怎么样使用的,本篇将会进行探究。
上篇中,我们初步探究了 RuoYi 项目是如何进行登录信息传输、验证码校验、密码校验,以及密码存储安全性方案。我们了解到,整个的验证实现是围绕 Shiro 框架进行的,而数据的传输安全性,RuoYi 是没有考虑的,如果我们做的是要求安全等级比较高的项目,需要考虑采用 https
协议,并对关键数据进行加密后传输,一般会使用非对称密码算法进行加解密。
本篇,我们主要会针对 Shiro 框架做一个简单的扩展了解,然后再初窥 RuoYi 的菜单、权限功能。
上篇中,我们初步观察了 RuoYi 的项目结构,并在最后实际运行起了项目。我们也发现了作者不好的代码习惯,作为反例,我们应该要养成良好的编码习惯。本篇开始,我们会按照 Web 界面逐一对具体子项目的实现的功能进行探秘。
我们正在探秘各种比较火热的后台管理相关的开源项目,探秘结果将以系列文章的形式分享。希望你能在这些文章中学习别人的优点,也能看到别人的不足,进而可以提升自我的技术能力或技术态度,不论是提升了什么,只要你有收获即可。
“你若不离不弃,我必生死相依”,是一句非常痴情的话,也常被人化用于孩子的名字,寄托父母美好的期望 。
今天要探的这个最火后台管理系统 RuoYi(若依),便是作者化用女儿的名字命名的项目。
本文翻译自 Using Redis on Cloud? Here are ten things you should know。
我们很难操作大规模的有状态的分布式系统,Redis 也一样不能例外。托管数据库承担了许多繁重的工作,让我们生活更加轻松。但你仍然需要一个良好的架构,并在服务器(Redis)和客户端(应用程序)上应用最佳实践。
本文涵盖了一系列与 Redis 相关的最佳实践、技巧和窍门,包括集群可伸缩性、客户端配置、集成、指标等。虽然我会不时引用 Amazon MemoryDB 和用于 Redis 的 ElastiCache ,但 大多数情况(即使不是全部)都适用于 Redis 集群。
在上一篇中,我们总结了与索引属性相关的 API。本篇中,我们将介绍一些特殊的管理 API,包括索引模板 API,对索引的监控和状态管理 API,还有特别的悬空索引。
在上一篇中,我们针对索引 API 相关管理 API 进行了总结,包括常见的 CRUD
及 Elasticsearch 特殊的 API。其中,我们提到,在 Elasticsearch 中,没有直接针对索引本身的“修改” API,而只能修改索引相关的属性。本篇,将介绍与属性相关的 API。
在 Elasticsearch 中,索引可被认作一种文档的优化集合,且每个文档都是字段的集合,字段是包含你数据的键值对。
也就是:索引 → 文档 → 字段 → 数据。
一般,我们如果开发了一个工具组件,肯定想将它发布以供其他人使用。在公司内部,我们可以将其发布到私有仓库,在互联网环境,我们一般将其发布到 maven 中央仓库。以下以我们最近开发的java工具 flyRafter
进行介绍,如何将一个组件发布到 maven 中央仓库。
上一篇中,我们按照官方文档直接体验了对 Elasticsearch 的安装,以及安装成功的校验。本篇我们按照官方对各种平台的安装方式,学习一下Elasticsearch 安装相关的基础信息,如目录结构,常见参数等。
想要尽快的熟悉一样东西的方法,就是去使用它,所以我们需要先把 Elasticsearch 运行起来,这样我们才能去使用它、学习它。
官方文档中介绍,最快的入门 Elasticsearch 的方法是在云中免费试用14天 Elasticsearch 服务。
官方概要介绍如下:
Elasticsearch 是位于 Elastic Stack 中心的分布式搜索和分析引擎。Logstach 和 Beats 促进采集、合计以及充实你的数据并在 Elasticsearch 中存储它们。Kibana 允许你去交互式的探索、可视化和共享对数据的见解,以及监视这个栈(Elastic Stack)。Elasticsearch 是索引、搜索和分析的神奇所在。
多年以后,我上着网还玩着各种电脑游戏时,准会想起哥哥们带我玩采蘑菇的那个遥远的下午。
本文介绍Jekyll代码高亮
GitHub Pages目前使用的Jekyll 3.0,和我们博客相关的特性就有:
在之前的文章GitHub Pages系列中,介绍了使用GitHub Pages搭建博客。但实际运行一段时间后发现,文章显示的时间是UTC时间,而不是北京时间。
显示效果如图所示:
本文介绍GitHub API基础及上传文件到仓库API,并应用API将GitHub作为图床
由于GitHub 的约定,一个账户只能拥有一个GitHub Pages,那么,如果你有多个想部署的静态网站(博客和文档等),它们是互相隔离的,如何用同一个GitHub账户进行部署呢?
从之前如何搭建GitHub Pages的系列文章用GitHub Pages搭建博客(一),我们知道Jekyll或者Hexo实现的静态网站的配置中,常常要指定一个当前网站的目录。
2020年的“双十一”又要来到。很多直男朋友又要陷入被女朋友、被老婆抱怨不懂浪漫的时刻。直男们纷纷感到很委屈:啥是浪漫啊? 我并不喜欢“直男”这个语汇。因为有“直”必有“弯”,虽然这不可否认,但当直男总被冠上“不懂浪漫”的标签时,不正是想表明“弯男”更懂浪漫么?可女性会和“弯男”在一起吗?答案是显而易见的。
前几日,博客园上出现了一篇文章《国内首个 .NET 5 框架 Fur 斩获 1000 stars,1.0.0-rc.final.20 发布》。此文一出,立即引发了吃瓜程序员的好奇,大家纷纷好奇:国产框架到了一个新的高度了吗?
本篇介绍GitHub Pages的一些杂项
本篇介绍百度统计、百度搜索
一般来讲,部署了一个网站后,我们需要知道网站的浏览量,以便知道网站是否有人访问。
本篇介绍GitHub Pages网站加速
在上一篇提到如何对GitHub Pages配置自定义域名。其实,不论GitHub Pages的默认域名还是自定义域名,都使用了GitHub的CDN进行加速,虽然速度还行,但总还是觉得有点慢。
本篇介绍GitHub Pages自定义域名
在**用GitHub Pages搭建博客(二)**中介绍到,默认的GitHub Pages域名就是仓库地址,即:
账号名.github.io
本篇介绍配置网站参数及发布文章
GitHub Pages一般使用的Jekyll,配置项基本都设置在_config.yml文件中,在此文件中,按参数描述进行配置即可。此处以上一篇使用的Jekyll主题为例进行介绍。
本篇介绍通过git工具替换网站主题,并发布。
本篇介绍基本GitHub Pages的搭建流程
GitHub官网介绍 GitHub Pages
官网是这样介绍的:
Websites for you and your projects.
给你和你的项目的网站。
Hosted directly from your GitHub repository. Just edit, push, and your changes are live.
从你的GitHub仓库中直接托管。只用编辑、发布,你的修改直接生效。
沈从文先生写了一篇小说《边城》,讲湘西的故事,以兼具抒情诗和小品文的优美笔触,描绘了湘西地区特有的风土人情;借船家少女翠翠的纯爱故事,展现出了人性的善良美好。
由于“边城”与“编程”的谐音,程序员之间,也会偶尔会调侃一句:沈从文先生可是咱们编程界的祖师爷。