一、优秀的估值产品

钉大在《定投十年 财务自由》和《指数基金投资指南》中不止一次提到过要结合估值来投资,为此,他每个交易日他的公众号银行螺丝钉中都会发布他编制的基金估值表,最新的一期已经是第2281期了。

这是钉大昨天(2023-11-21)晚上发布的估值表。绿色表示低估,黄色表示居中,红色表示高估。

这篇博客首发于古月居,如若转载,请注明出处:古月居 http://www.guyuehome.com/45164

我在以前的博客中提到过,我在工作中大量使用ChatGPT(GPT4-32k)来辅助我,方案设计、函数编写、code review、编写测试案例以及Debug等等,虽然它做不到完全正确,但是作为一个辅助和参考工具,还是非常有用的。

这次为OriginBot开发监控功能的时候就想尝试用GPT4来完整地开发这个功能,我以前从来没有让GPT4做过完整的任务,因为它受限于上下文的长度,很难完成大型的任务。这是一次尝试,不过从结果来看,还是很不错的。

买过基金的人应该都是知道,买基金是会被收取费用的,今天整理一下关于基金费用的问题,以下内容只是我学习到的,不保证真实性,需要自行甄别。

特别:这篇博客里面很多内容参考了钉大《定投十年·财务自由》这本书,非常推荐大家去看一下。

不知道有没有跟我一样,以前觉得在天天基金这样的平台上买基金不用太关注费用问题,因为现在费率相较于以前在银行买基金已经非常低了,大家相差不是很大,不用花时间研究。

现在后端开发基本上都是写各种API提供给别人使用,我在日常工作里既写API,也经常调用别人写的API。

分享一下经常使用的调用API的模块。

看代码之前会有一些假设,可以帮助理解代码。

指数基金投资指南

这篇博客里面的内容主要来自于银行螺丝钉的《定投十年,财务自由》和《指数基金投资指南》这两本书中章“常见的宽基指数”,最近第三次读这本书,打算做一点笔记加深自己的印象。

博客中很多内容是从书中摘抄的,涉及版权问题,已经征得了钉大的同意。


一、简介

MQTT 是 Message Queuing Telemetry Transport 的缩写,是一种轻量级的、基于发布/订阅模式的物联网通信协议。它具有以下特点:

  • 简单易用:MQTT 的协议规范很简单,易于学习和使用。
  • 可靠性高:MQTT 使用了 TCP 协议进行传输,具有较高的可靠性。
  • 低延迟:MQTT 使用了发布/订阅模式,可以减少消息传递的延迟。

JWT简介

JWT(JSON Web Token)是一种流行的跨域认证解决方案。它可以在令牌中安全地传输用户身份信息,实现无状态认证机制。

优点:

通过runserver运行Django

相信用过Django做开发的人对于python manage.py runserver 这个命令一定不陌生,这个命令利用django自带的一个web服务器,可以帮助我们在本地很简单地就运行django,对于本地测试来说足够了,但是不能用作生产环境中,甚至测试环境都不行,主要有如下几点问题:

  1. 性能差
    它是单进程、单线程的,因此只能同时处理一个请求。随着请求量的增加,服务器的 CPU 和内存使用率会不断上升,最终导致性能下降

  2. 功能有限
    它仅支持基本的 HTTP 请求,不支持 HTTPS、负载均衡、静态文件服务等功能。在生产环境中,这些功能是必不可少的。

软件能2

《软技能》这本书可以说在互联网行业里面是家喻户晓了,前一段时间想读的时候发现作者去年8月出了新版,依然沿用了之前的名字,全名叫做《软技能2 · 代码之外的生存之道》,就选择了阅读新版。

这本书的作者 约翰·Z.森梅兹 本身也是一名开发者,根据书里面零散的信息,他刚工作的时候是开发打印机驱动程序的,后来做软件测试工作,再后来做互联网软件开发工作,整体上还是有比较大的变动的,他都能成功转过来,并且都做的很好,不得不佩服。

约翰·Z.森梅兹 在19岁的时候(也就是1988年,这个信息来自于 google bard )年薪就已经6位数了,即使在35年后的今天,这个薪资依然是很不错的,不过美国的通货膨胀不高,不能用中国的情况去类比。


如何开一家小而美的店
上面这张图是我用这本书的标题“如何开一家小而美的店”作为Prompt,利用百度的文心一言画出来的图片,感觉并没有准确表达标题的意思,不过也挺有意思的,就放在这里。

这本书从8月开始阅读,断断续续读了两个月,一直到9月底才读完。

我前年拿到了房子,前年10月开始装修,装修过程中发现新小区附近没有一个像样的水果店,就动了开一个水果店的心思,虽然后来不了了之,但是心里就一直留下了一个开店的念头,所以看到这本书的时候就很想读。

我老婆那时候很想开一家干洗店,我觉得投入有点大,也没有实际去做,结果今年小区楼下真的开了一家干洗店,现在看感觉生意还挺好的,感觉错过一个挣钱的好机会呀…


昨天和今天上午参加了公司组织一个关于“客户沟通”的培训。

我的工作中,写代码大约占35%,任务管理、运维等占30%,沟通大约占据35%。

我参与一个异常检测的开发项目,还负责两个DevOps相关的工具,几个月前开始负责我们团队的全球支持工作,经常需要跟用户沟通,了解他们的使用情况和反馈以便帮助我进行改善,还会基于日志和流量做一些用户行为分析相关的工作,分析出来的场景和问题也要跟用户沟通来确定分析的对不对,虽然有一个同事会帮我分担一些简单、重复的沟通,但是总得来说,沟通对我而言还是很重要的,这也是我为什么会报名参加这个培训的原因。

用Django好几年了,期间陆陆续续因为项目开发需要看过一点点源码,但是一直没有整体上看过源码,最近在B站上发现了一个不错的Django源码讲解教程,**沈奇才·Django4.0源码解读,打算跟着这个视频过一遍,不过我看到的目前最新的代码,我从Django的官方仓库fork了一份代码,yexia553/django** ,后面把想相关的注释和说明都提交在这个仓库的learning分支上。

我不打算逐行解释代码,只会记录一些我觉得写的不错或者对我理解Django的设计有帮助的内容。

这篇博客会记录一下django.conf.settings相关的代码,也就是Django中的项目配置相关的部分。

global_settings

芯片战争

从去年买了微信读书的会员开始,到现在一共读(听)了27本书,其中有三本是晚上睡觉时候听的玄幻类的小说,所以真正读的是24本。

虽然读了24本书,但有时候看着读过的书名,却不太记得里面的具体内容是什么了。
一般来说,我会读完的书都是我觉得还不错的,虽说读书不是为了完全记住里面的内容,但还是希望能加深自己对这些书的印象,所以打算开始写“读书笔记”。

我给“读书笔记”加了引号,是想区别于读书的时候学校教我们的读书笔记,我只打算简单、随便地写一点书里面的内容一遍帮助我加深印象,而不会刻意地写积极向上的感想。

中国的芯片产业

Service分发负载的策略

大家都知道,一个service可以对应多个pod,那么一定要有一些方法来把service接收到的请求(负载)转发到pod上。
一般来说,有两种策略,一种是轮询,还有一种会话状态保持。

轮询策略很简单,就不多说了,这也是service的默认策略,在不做什么相关配置的情况下就是使用轮询策略的。

原文地址:HOW TO DO GREAT WORK
作者: Paul Graham
时间:2023年7月

我年初决定开始翻译保罗·格雷厄姆的博客,前面翻译了两篇。这篇博客之前,最近的博客的是2023年1月的,这篇博客是7月发布的。没想到保罗大叔用6个月时间憋了一个大招,写了一个19000多字的博客,谁家好人一篇博客写这么多字啊….我写了64篇博客,加起来才10万字左右

这篇博客我翻译了差不多一个月,终于翻译完了,中间数次想放弃,又想想都已经翻译了那么多了,放弃太可惜了

之所以决定翻译保罗大叔的博客,一是因为我很喜欢他的博客,目前还没有稳定的中文翻译站点,就打算自己做;二是锻炼自己的英语,在英文环境中工作了3年多,越来越感觉自己的英文水平受到了词汇量的限制,打算借此多学一点词汇和句式。

我是先用谷歌翻译翻译全文,然后自己再逐段修改。有很多内容,虽然看英文能理解原文的意思,但是想要翻译成合适的中文真的挺难的,起码对我来说是这样的。

如果你收集了在很多不同的领域做出伟大工作所需要的技能列表,那么他们的交叉点会是什么样子的?我决定通过实践来找出答案。

签约作者

古月居是国内最大的机器人社区之一,我去年11月买了他们的开源机器人OriginBot,也因此跟他们有了接触,后来在今年1月份跟古月居签合同,成了他们的签约作者。

之所以答应跟古月居签约有三个原因:

老实说,我其实不是一个标准的“程序员”,但对于不是这个行业的人很难解释其中的区别,而且我也对于这篇博客中谈论的问题印象深刻,还是想写一下。

我在公司的title是Sr. DevOos Engineer,也就是资深(高级)DevOps工程师,写代码只占我工作量的40%左右。

前几年,网上以程序猿来戏称我们这个行业的人,下面这张图也一度很流行。
程序猿

官方其实提供了自动导航方案了,https://www.originbot.org/application/navigation/#4

但是这个方案里最不好的地方在于需要通过rviz手动指定具体的目标点和姿势才能驱动OriginBot进行导航,也就是手动的自动导航,这个就限制了后续基于这个功能做拓展的可能,因为总不能每次需要导航的时候都手动在rviz上做吧。

所以我就想用代码来实现这一块功能,以下是目前探索出来的部分,欢迎交流。

我最近开始更新微信公众号,但是公众号的发布流程很复杂,即使我已经有现成的博客,但是发布到公众号上也要花很长时间,于是就开发了一个工具来帮助我自动更新公众号。

我从2020年开始写博客,到现在已经有大约五六十篇了,一篇篇手动在公众号发布一次要做很久,而且都是重复劳动,就不是很愿意做。

而且我一直都是用markdown来写博客的,即使现在手动把库存的博客发布到公众号,以后还是要一直手动更新,因为公众号是一个封闭的系统,编辑和管理文章都有自己的一套方案,长期来说,这也是一个麻烦。

今天突然就想看一下关于k8s和虚拟机的优劣势对比,我就问了一下chatGPT,我用的是公司提供的Azure OPENAI服务,以下ChatGPT的回复。

(这样的回复对于一个熟悉k8s的人来说,显然不会很惊艳,但是也不错了)

我的问题

0%