V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  sujin190  ›  全部回复第 4 页 / 共 122 页
回复总数  2429
1  2  3  4  5  6  7  8  9  10 ... 122  
没啥不可以,只不过没现成的 Android GUI 适配基础库呗,你可以去做下适配那不就可以写了,Android 的窗口管理、绘图和消息事件都可以越过 java 写的 framework 直接调 native 库,写个 php c 扩展适配下就可以写 Android 客户端了啊,所以不存在不可以的情况吧,只不过好像用处不大,毕竟越过 framework 毕竟不方便而且 php 也没这生态啊
134 天前
回复了 Cosset 创建的主题 Linux Keepalived 不互通问题
怎么着也脱离不开虚拟网卡、路由表、arp 这些信息吧,不通就看看有没有正确的生成这些信息呗,你这样问没人能只读啥问题吧
@dongzhuo777 #93 我司这个是既不按业务边界划分也不按组织架构划分,通过各种接口各种 mq 消息相互调,接口消息感觉就是想改就改,前向后向兼容几乎不咋考虑,也就是流量实在太低,各种人工改数据修正搞得定,客户不会分分钟打爆客服电话,否则感觉就是分分钟崩溃的节奏,都无语死了。。
141 天前
回复了 HarrisIce 创建的主题 问与答 自动驾驶如何应对大模型的幻觉问题的?
好比就算是人也有脑子锈逗作死的时候,但是你的条件反射会直接纠正你的作死,自动驾驶也是同理,高层级大模型智能和低层里传感器条件反射防作死
141 天前
回复了 HarrisIce 创建的主题 问与答 自动驾驶如何应对大模型的幻觉问题的?
大模型不是只有生成式这一种好吧,好像也没有人说自动驾驶的大模型和 gpt 是同一种好吧,再说自动驾驶每秒需要读取传感器很多次输出很多次结果,单次识别异常并不会造成致命结果

而且更重要的是高层级的大模型输出会受到低层级的传感器直接限制,比如就算大模型识别异常发出撞上去指令,但是雷达距离这种直接的物理规则可以非常直接的限制该指令无效啊
@dongzhuo777 #69 暂停你这个说法,不是微服务不行,是实际过程中各种过度设计的,不应该拆的要么不知道怎么搞项目架构设计要么偷懒,各种该拆不该拆微服务的都瞎拆,还有各种循环依赖循环调用,各种兼容性不管疯狂开新版本接口,各种日志不按规则写瞎写乱写的,链路追踪什么的瞎弄不统一,我司就是这样的,好好的给他们弄一波,过不了三个月又乱七八糟了,不是微服务不行,就这样的单体服务一样乱七八糟好不到哪去
@soar0712 #8 本质逻辑还是相同需求可以有不同方式表达,不一定非要用这种直接粗暴的方式由最底层的数据结构来完成,而且实际工程中,业务流和数据流不一定要一致,业务流程不可避免需要逆方向,但是数据流随时间往前应该尽可能不逆方向

更进一步在你提出的角色这个场景中业务流程中随时间方向需要删除角色并没有逆方向,但是数据流按你这么设计却并未保持随时间方向而是出现了逆方向,这种逻辑在实际过程中会导致非常多的问题
141 天前
回复了 lambdaq 创建的主题 随想 无人驾驶如果违章,扣谁的驾照分?
@lambdaq #11 违章也是一样的,人才会违章,自动驾驶是机器只有生产事故
实际工程上正在使用的角色或模板不允许删除实际上才是更好用的,否则用户会给你搞出各种各样的毛病出来,而且后续一通乱改加各种需求流程后,你会发现各种想到想不到的地方都会和你角色、模板什么的有关联,所以一般来说还是让这种处于流程源头的关联关系使用中不让删才是最科学的,产品需求的话也可以用交互来满足啊,不一定就在底层数据逻辑上来满足,比如提示用户并给出一种相对方便的方式让用户完成解绑不再使用就是了
141 天前
回复了 lambdaq 创建的主题 随想 无人驾驶如果违章,扣谁的驾照分?
@lambdaq #4 罚企业钱呗


@lambdaq #4 @ar16 #5 交通肇事罪针对的是人主观意图犯罪,无人驾驶是机器故障,属于生产事故,无人驾驶企业自然人顶多是监管失责或者是失职,包括未经合理测试验证等等都一样,并不适用于交通肇事罪吧,交通违章也是类似的,扣分什么的就更不存在了,估计就是罚钱或暂停整改,屡教不改或者造成重大事故的就吊销自动驾驶拍照呗,当然造成的损失肯定是由企业来赔偿了
我是用手机 gps 记录器给 hss 上报位置,由 hss 控制米家空调伴侣来关空调、灯什么的,还可以设什么离开公司下班、到家附近提前打开空调什么的
145 天前
回复了 xFrank 创建的主题 程序员 请教一个涉及前向兼容的 API 设计问题
感觉比较好的方式是添加一个 error_details 数组结构化字段,里边详细包含各种细节错误信息,一级的 error_code 只用来表示错误大类别,一般来说 error_code 决定大业务流程方向,在保证 error_code 能完整完成业务流程情况下,error_details 提供细节优化,实际情况下就算后续 error_details 进行调整了不兼容也能保证业务流程能正常完成,只不过纠错、提示或者交互不那么优化而已,毕竟大的业务流程总不能说改就改吧,否则你这兼容性感觉没法弄
@MozzieW #7 我猜加密的时候有个 table_s1 table_s2 table_s3 table_s4 ,ab 是 4 个字节,key 也是 4 个字节,这样就可以用 descrypt 差不多算法来加密了,估计重点估计是这个 table1-8 是怎么构造出来的,单这样看估计确实看不出啥来也不符合逻辑
158 天前
回复了 lllei 创建的主题 数据库 很好奇飞书的数据库表是咋设计的
或者复杂的还可以进一步分成用户表、账户表、档案表和通行证表,你说的工位,工号,分组号这种会动态变化的一般都属于档案信息,基于用户档案信息通用性相关及查询效率优化,用户档案还可能进一步分成基础档案表和扩展档案表,业务逻辑一般都是用用户表来串联的,这个表几乎不可能会修改,也保证了各业务系统可以可靠依赖用户信息,而档案信息其它业务系统需要使用也必需直接从用户系统通过接口实时获取,这样档案数据结构修改就要容易很多了影响也小
158 天前
回复了 lllei 创建的主题 数据库 很好奇飞书的数据库表是咋设计的
用户表这种作为核心流程的表,基本设计原则应该是核心字段横表且固定不轻易修改,非核心字段纵表 KV 动态扩展,也就是常规用户信息都会分为 user 表和 profile 表,虽然数据库表加字段确实很容易,但是核心表三天两头改字段真的是在给自己加很多班,以及上面什么自定义字段什么存 json 什么 mongodb 动态都很坑,毕竟用户表作为核心流程几乎串联了整个系统,必需稳定且可靠,关于哪些是核心字段哪些是非核心字段就看设计功力了
而且看政策,城市场景中,这种必需在特定审核批准的起降场起降,后续需要沿着备案的特定飞行路径和高度飞行,低空空域也不高,估计顶多能规划 3 层的飞行空域,现行情况下估计几乎不可能有什么空中红绿灯,所以也必然需要起飞前就规划好不会和其它人冲突才能起飞,所以随时起飞,以及想怎么飞就怎么飞也是不可能的
@lei2j #3 也没用吧,相比地面通行来说,一线大城市这种级别同时上路的车估计能有几十上百万辆,但是能够载人的飞行器同时飞行的数量估计也就千级别,送外卖快递这种小型飞行器估计也就万级别,相比总需求来说真的不值一提,跨区飞行想法挺好但是因为不安全因素大幅变多了,通行容量和时效根本不可能太高,容量太低注定只能是奢侈品,大多数人看看就好了
高价值货运和有钱人玩具,和普通人关联不大吧,毕竟空中通行容量比地面低太多,这么低通行容量下什么送外卖送快递通勤什么都是扯淡,只不过现在毕竟空白,行业还是可以发展一波的,只是天花板太低,爆发增长大多数人能收益估计不大可能,好看不中用的类型
1  2  3  4  5  6  7  8  9  10 ... 122  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1346 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 35ms · UTC 17:51 · PVG 01:51 · LAX 09:51 · JFK 12:51
Developed with CodeLauncher
♥ Do have faith in what you're doing.