可能我们这一代人赶上了几次技术的大突破就把这个当成习惯了,互联网,移动互联网,AI. 8 年过去了, 别说智能家居行业,就是整个大互联网行业, 有几个 8 年前后的对比，有很多惊喜的? GPT 可能算一个, 其他呢?

扫地机,基础的场景早就稳定了, 后续上下水基站可能算一个创意突破, 再往后就是拼算法了,可不是创意和代码可以解决的.
再说门锁,用户最核心的需要场景其实就那么几个,再往后拼的可不就是你说的稳定性这些"玄学"? 以及指纹识别,人脸识别这些算法上?

这些算法如果没有显著的技术进步,这些体验都很难有质的提升. 但是很可惜,这几年算法的进步都往大模型走了, 这方面的进步似乎并不多.

另外说到互联互通, 如果仅仅是通,可以国内可以看看小米或者百度的生态,海外可以看看 Matter 和 HA 生态. 但通了之后,除了少装一个 App 外(现在手机存储大了,这个问题好像也不是那么痛了), 互动的场景又有多少是真的需求?

总结一下, 能用创意解决的场景,需求枯竭,包括苹果在内都没有好的场景;痛点方面,技术(基本都是算法)又跟不上. 所以这可能根本不是"代码和创意"的问题. 移动互联网到来之前,互联的的创意已经非常少了,移动互联网一来,创意就如雨后春笋了. 这个世界的发展本来就是螺旋上升.

这样做有一个限制,就是设备和设备之间的互发消息必须少,而且需要你通过业务来转发实现.如果这种转发太多且无规律,实际上你就是一个 Broker 集群了. 一般来说,需要通过你的业务来简化这个模型.比如一般的物联网场景下,设备和设备之间是不需要相互发消息的,但如果你有网关类设备,就又不一样了,需要特殊处理.

@laters 有这个问题是因为你的两个 Broker 没有组成集群,这要看你问题规模.
1. 如果规模小,就建集群,往哪个 broker 发另一个都能收到的.你可以想象成 Client A 连接了 Broker A,订阅了 a topic, B 连 B,然后给 a topic 发 pub. 问题是集群是有上限和代价的,特别是社区版.
2. 如果规模大,集群搞不定或者不想买商业版,那就自己控制路由.设备连 Broker 之前,通过接口拿到节点的域名(如何分配看你的业务),然后再连接.这样 Broker 之间没有联系,集群规模的大小就只受你业务能力的限制.当然,为了高可用,实际上你的每个节点还是一个小集群,但这是另外一个故事.

@zhaidoudou123 有扫描的,但是海外的用户似乎有一部分非常排斥扫码

Please note that Apple does not investigate claims regarding branded terms used as Search Ads keywords

这里明确说了用他人品牌投广告的投诉是不会受理的,那么应该往哪个方向来投诉呢?

看你为什么要用 Linux,为了折腾,"学习"怎么都行,但就生产力来说,用 Linux 不是因为绝大多数开源软件的适配,安装省心吗? 所以去各大开源软件的 install 里找找看,选排在最前面的就好了.

想省事可以试试这种 https://www.amazonaws.cn/en/dynamodb/

@dfkjgklfdjg
感觉还是不太一样.
这个帖子里描述的是他的页面显示了 url 中的参数,导致搜索引擎认为这个页面确实有相关的内容. 但这里 URL 的"Z1JFV=.txt20230625A0NFK"这些内容明显不涉及关键词.

https://isocpp.org/wiki/faq/dtors#order-dtors-for-locals

这种问题来源比答案重要

What’s the order that local objects are destructed?
In reverse order of construction: First constructed, last destructed.

In the following example, b’s destructor will be executed first, then a’s destructor:

void userCode()
{
Fred a;
Fred b;
// ...
}

来围观需求描述的认知偏差了.

像 @gzlock 这样的 4 条命令行, 2k 并不少吧, 毕竟他都送了 2 条了.

插件能力开放给 API? 另外盲猜 SDK 里可能也会有一些官方的描述 api 的 prompt 放出来

markdown 直接放到 gitlab 私有仓库，画图用 plantuml 的语法。分享的话用自定义扩展语法，写个小脚本用 cicd 同步到 gist ，比如下面这种，支持图片和 plantuml ，自用够了，其他语法可以添加起来应该也不难。
https://github.com/xylophone21/gist-sync

机场私人用用就算了, 如果你是公司用, 你猜有人发布"非法"言论后会找谁?

个人感觉是更方便的搜索引擎,比如问一些小算法,库的使用,都比 Google 要快. 这些问题有一个共性, 就是你很容易把需求描述清楚.
反过来说,既然不能写代码是因为很难把需求描述清楚(问题太复杂,超过范围也算不能在限制条件下描述清楚), 其实你反过来, 贴一段代码给他,请他帮你找问题或者解释, 也是很好用的.

外面传一个指针进来,在函数里面赋值. 内存逃逸问题,空对象问题,都解决了. C/C++里都是这么干的, 用起来会烦一些, 性能提升可能也不多, 看你的场景到底在不在乎, 以及这个代码你打算用多久.

可能会涉及一些系统 app,调用隐藏 api 甚至私有 api.
可能会涉及一些行业知识

暂时就能猜到这么多

@simonlu9 好的, 我的问题就是这个并不是 git flow.

另外你提到 develop 分支没有用,所有功能都合入 test 分支,(再合并到 master 分支上线),感觉这其实更像 gitlab flow. test = master, master = production/stable. 但问题还在 gitlab 分支是从 master 开发,而非 production/stable. 也就是违背了上游优先原则.

@wolfie
@caicaiwoshishui
@brader
@TArysiyehua
@simonlu9
@NerbraskaGuy
@biubiu001
@karott7


https://gitee.com/jadepeng/pic/raw/master/pic/2021/2/2/1612267487337.png

看到几位说这个符合 git flow,但如图 git flow 中的 feature 分支(即每次开发)都是从 develop 分支来的. 不知道我哪里理解错了.

用 github flow 比较多, 但如果我没有理解错,git flow 每次是从开发分支拉出来开发, 而不是从生产分支拉. 也就是”上游优先”原则. op 的操作每次从生产分支拉, 大致相当于"下游优先"了, 很多已经在上游修改过的东西, 你一拉分支,就又没有了,可能不自觉又从新改了一遍, 所以冲突很多.

如果你们有大量功能开发持续时间很长, 而且和现有模块又高度相关而不是新写一个模块(其实我有一点怀疑, 因为这里有 3 个关键词, 大量,持续时间很长,高度相关, 换句话说你们经常性的把已有模块翻来翻去 -- 如果是重构, 不符合大量, 如果是原代码结构比较差, 总要改则不符合时间很长; 如果结构好,每次都是扩展一个子类新写一个模块, 不符合高度相关), 那么可以尝试一下 gitlab flow, 否则 github flow 真的很简单好用.

>> 每个人的开发分支是从生产分支拉的，每个人开发完自己的需求后合并到测试分支。