kubeapps：基于helm仓库快速部署应用的WebUI
octosql：跨数据库查询分析工具，当前支持JSON、CSV、PostgreSQL、MySQL、Redis 配置文件如下：
dataSources: - name: cats type: csv config: path: "~/Documents/cats.csv" - name: people type: redis config: address: "localhost:6379" password: "" databaseIndex: 0 databaseKeyName: "id" sql:
octosql "SELECT p.city, FIRST(c.name), COUNT(DISTINCT c.name) cats, SUM(c.livesleft) catlives FROM cats c JOIN people p ON c.ownerid = p.id GROUP BY p.city ORDER BY catlives DESC LIMIT 9" 输出：
+---------+--------------+------+----------+ | p.city | c.name_first | cats | catlives | +---------+--------------+------+----------+ | Warren | Zoey | 68 | 570 | | Gadsden | Snickers | 52 | 388 | | Staples | Harley | 54 | 383 | | Buxton | Lucky | 45 | 373 | | Bethany | Princess | 46 | 366 | | Noxen | Sheba | 49 | 361 | | Yorklyn | Scooter | 45 | 359 | | Tuttle | Toby | 57 | 356 | | Ada | Jasmine | 49 | 351 | +---------+--------------+------+----------+
对于采用微服务架构的业务系统来说，很难做到只更新自身服务的数据，更多是要通知其它服务,哪些单据或档案由什么变成了什么。Outbox Pattern 使源服务 “read your own writes”，同时提供跨服务可靠，最终一致的数据交换。
微服务，最头疼的地方就是数据问题，如果你也曾经在业务系统中使用，一定深有体会。关于其它方案的探讨就不再深入了，感兴趣的可以看一下：Reliable Microservices Data Exchange With the Outbox Pattern 接下来只是照本宣科，应用到自己系统中。
注意：该模式与特定的实现选择并无关系，是否使用ORM，使用JPA/Hibernate，Spring Boot，等其它技术，其它语言。现在讨论一此细节 Outbox Table 的表结构：
Column | Type | Modifiers --------------+------------------------+----------- id | uuid | not null aggregatetype | character varying(255) | not null aggregateid | character varying(255) | not null type | character varying(255) | not null payload | jsonb | not null id: 事件的唯一标识; 可以用于消费者判断是否重复消息.
aggregatetype: 事件产生者的类型，比如生产订单.
aggregateid: 事件产生者的ID
前提，基于这个项目的dbsinks kafka connector
创建stream
create stream stream_name with (kafka_topic='topic', value_format='avro'); SET 'auto.offset.reset' = 'earliest'; run select
select after->"ID" from stream_name limit 1;
作为一名开发人员，其实整个职业生涯可能大部分的时间花在了踩坑、填坑（写bug、修复bug）上。就算是学习也是一种递归： 打算学A，A依赖B，然后学B，B依赖C。。。最后的结果就是要么学到XYZ，要么放弃。不忘初心好难，学到最后已经不记得最初想学的是什么了。
confluent-kafka-goconfluent出品，正好与工作中的kafka 相关，粗略看了一下，文档还不错。个人习惯，接下来马上Getting Started，第一步：Installing librdkafka，然后就没有第二步了，因为 第一步我卡住了，手头只有windows，通过WSL使用Remote Development 是一种解决办法，不过前几天刚刚卸载了，C盘空间不允许了。不过它倒是提供了一个思路，就是通过Docker，以下是具体过程(以windows为例)：官方链接
安装Docker Desktop for Windows,并设置代码所在盘符为共享盘 这一句的作用其实不太明白
git config --global core.autocrlf false Install Visual Studio Code Insiders
Install the Remote Development extension pack.
Ctrl+Shift+P Remote-Container:Attach to running container
注：vscode 的*Remote Development*与docker 两个插件真的是神器级别的
前一段时间发生了一场车祸，骑自行车时被汽车追尾了，不巧的是头碰马路牙子上了。。。出院后发现本就不理想的记忆力越发衰退。 所以萌生了还是写下来吧，当成个人历史的银行。
这几天一直在研究Kafka的Connector。起因是偶然发了debezium这个项目，正好工作中有类似需求，谁知跟着get starting走下来， 发现这是一神器，监听数据的CRUD然后以topic的方式给kafka，这样就可以针对这些topic做太多事了，数据清洗、迁移；系统扩展、系统对接等等。 在随后的blog会写一个基于微服务多数据库(mysql)sink到postgresql单数据库中，作为帆软报表数据源，一定要近快，不知道这个过程在大脑中还 可以清晰多久。docker项目
时常会遇到不错的github项目，以前一直在用chrome的bookmarks,但随着收藏的越来越多，意义越来越小，因为找半天还不如直接google。 用了一段时间的Bookmar Search，但 效果不佳，因为前提是我必须记得自己要找什么，这个难度对我来说太大了。其实我很清楚写blog时间久了肯定也会有这个问题，但对于一个懒人，能写 到blog里的一定是非常重要的。
本次要记录的是两个分布式消息平台nsq、nats， 感觉都不如kafka，或者环肥燕瘦吧，Pros和Cons网上比较很多。nats是因为go-micro练习grpc时用了一下，谈不上研究，研究简单易用，nsq没研究， 暂不评价。