颇多的事，接连多变，颇多的想法
时间也是过得快啊，不知不觉好像离高考做题那阵子都过去一年了，想想一年前, 还是在疯狂沉浸于做给自己玩的Modpack，想起最后一次碰钢琴还是在高考地理的那个早上，回想我的高中，总还是一时难评，虽然我不是一个喜欢追忆过去的人，但硬要想，我依然想说，我可能会怀念那里的人和事，而不是这所中学吧，在三年应试逼迫下，留给我美好印象的事，可能还是上晚自习偷偷溜去弹琴、半夜待在教学楼偷偷看我推第二季、以及各种请假溜出学校提着行李箱走在与中学校园一墙之隔的通往BRT的路上的喜悦瞬间吧。
记得初中的时候，那时候痴迷于做题、物竞、数竞，想想可能是非常典型的‘别人家的孩子’吧呵呵，那时思想倒也年轻，还是在私立，又是小班化，办事也没有什么行政琐事，班主任即校长，虽然说倒也是在高强度的应试，但是总之还是比较人性化的，尚没有感受到太多的不适，记得当时好像是有个新宿管比较喜欢骂人，当时这种事都可以直接去和班主任沟通，还有学生也可以对老师的授课方式提建议，这在我三年后的高中里看来这种行为简直是异想天开，还没意识到一个common的中学与中学生活应该是怎么样的，当时想着就是考...
很忙碌的一段最近时光，一边先是写项目的agent监控日志模块，中间不知不觉就用到了OpenTelemetry, 是在CNCF下的一个孵化项目，顺便看了看OpenTelemetry的社区， 感觉是非常有活力的一帮人，他们的社区讨论会议是完全公开的，好奇还试了下点进去
说到OpenTelemetry, 虽然感觉还没有知名到大众化的地步，但是现在越来越多的企业和项目已经开始用它了，agent和可观测后端都在对接，我想OpenTelemetry想要实现的可观测标准在现在agent时代是喝到汤了，可以想象这个项目应该是是很有未来的。自己在用OpenTelemetry去对接agent的时候，也感觉算是第一次能够站在这么前沿的方向上。otel整个项目的宗旨是极好的，供应商中立，还能zero-code, 几乎是无痛接入otel collector， 引入之后也不影响可观测数据走其他标准，对可观测后端兼容性也是非常好的
Ouath2.0的WorkflowOuath2.0ouath2.0是一种授权协议它的存在是为了“一个应用如何在不拿到用户密码的情况下，访问用户在另一个系统的数据？”，平常网站里跳出来的第三方登录诸如使用google账号登录、微信登录实际上用的都是这一套协议，从而实现了比如你能够用google账号授权登录一个网站，但是网站拿不到你的google账号密码
Ouath2.0中大概可以分为这几个交互主体：
用户
网站前端
网站后端
授权服务器
资源服务器
Ouath2.0流程：以下是一种安全的通常实现
用户打开网站 example.com
网站发现用户尚未登录 ——> 跳转到授权服务器提供界面(同时也会带上后面要用到的重定向地址)
用户在授权服务器提供界面上输入账号密码（或者其他授权操作）
授权成功之后授权服务器返回临时code, 用户浏览器带上code重定向到之前给的重定向地址app.com/callback?code=123
网站后端收到网站前端带来的临时code，并拿着该code去找授权服务器换Accesstoken
授权服务器确认并发送Access...
业务逻辑-cdn持久化存储缓存以及更新cdn缓存这里以通过微信登录时缓存微信头像图片为例cdn缓存是什么：
cdn是网络上提供缓存服务的节点，用于减轻访问压力，并降低对第三方的依赖
比如用户在通过微信登录的时候会提供自己头像的url, 当我们不使用cdn缓存的时候，由于微信头像的url是不稳定的，当你的微信头像更换之后，原来的url会失效，最终导致网页根据该url解析的头像图片失效
而如果采用cdn缓存，会将当前url的图片缓存到cdn节点，之后网页头像图片的获取就从cdn来，哪怕原头像图片对应的微信url失效，网页头像依旧正常
接下来是更新cdn缓存和网页头像的一套业务逻辑模块，头像url分为以下三种：
userInfo.AvatarUrl为新头像：当前这次登录时获取到最新的微信头像
user.Avatar为网页头像：网页显示的头像
user.PermanentAvatar为获取cdn缓存的url
12345678910111213141516171819202122232425·········//在覆盖之前捕获之前存储的旧头像oldAvatarUrl := getUs...
目前网上检索到的关于Swift的REST API Call实现很多已经在swift6之后算是过时了的，Swift6强化了并发安全，以及URLsession API也相应增加了async版本（旧版本使用callback），更modern的方法是使用async/await以及Task来构建REST API Call
以下均使用URLsession进行REST API Call
在旧版Swift中, Get接口是这么call的
12345678910111213141516171819202122232425 func fetchPage(completion: @escaping (Result<PageData, Error>) -> Void) { let url = URL(string: "http://127.0.0.1:8080/community/page/get")! URLSession.shared.dataTask(with: url) { data, response, er...
用Swift写了一个从后端获取数据来展示话题和评论的Mac客户端, 用了MVVM模式
MVVM即Model、View和ViewModel
View层:
UI界面，对的，记住它就仅仅是个UI
ViewModel层:
View要用到的所有数据和方法，嗯，data和function，所以它在Swift中通常是个class
Mode层l:
底层数据和业务逻辑，在这个例子中包括向后端发出请求的底层方法，以及对应得到的json数据转换为的结构体
用ViewModel是为了视图和业务逻辑之间的解耦从我的项目文件结构中应该能更加清晰说明这个：
-CommentSystem
-PageModel.swift
-PageService.swift
-PageData.swift
-PageViewModel.swift
-PageView.swift
...
写这个项目的时候本来用来理清需求和思路， 后来稍微添了点就顺便出来一份规范点的易上手文档，仅供参考
存储技术文档后端项目：你可能需要的文档：
补充后端基础知识 https://youtu.be/XBu54nfzxAQ?si=0Ce6-dFM4nokSlwb
（JWT入门）Spring Boot 如何集成JWT实现Token验证https://cloud.tencent.com/developer/article/2245008
Spring Boot 零基础快速入门https://kucw.io/blog/springboot/1/
Spring Boot Restful API介绍https://kucw.io/blog/springboot/22/
spring与数据库的交互方式 https://dimitri.codes/difference-spring-data-jdbc-jpa/
要求：
系统需求: 支持 Markdown 文件的上传、元数据存储以及权限化的访问管理
用户与权限: 支持基础的JWT认证, 角色权限可以分成User/Admin
...
为防止init_commit的重复创建，应把init_commit写入.gitlet,一次创建，其他地方直接引用
sha接受byte数组，需要readContents先转化为 byte[]
暂存区分tobeadded和tobeDeleted两种
获取timeStamp:
123Date now = new Date();Date inittime = new Date(0);//the init time 'Thursday, 1 January 1970'
转换得到String类型的timeStamp
1234static String dateToTimeStamp(Date date) { DateFormat dateFormat = new SimpleDateFormat("EEE MMM d HH:mm:ss yyyy Z", Locale.US); return dateFormat.format(date); }
对于每个commit，其hashID通常这样...