V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  passerbytiny  ›  全部回复第 29 页 / 共 153 页
回复总数  3054
1 ... 25  26  27  28  29  30  31  32  33  34 ... 153  
2020-03-18 11:26:36 +08:00
回复了 yyh0808 创建的主题 分享发现 关于招行 app 语音窃听
@vanxy #108 “block”属于无效回复,我就在加一个: 呵呵。

写完上面的回复我扫了一眼,发现你还惹了其他人,再加一个呵呵。
2020-03-18 11:02:42 +08:00
回复了 passerbytiny 创建的主题 问与答 找个可方以在 Android 上 7*24 小时挂的某服务的部署案
怎么今天人这么少,40 分钟才只有 15 个查看,并且零回复还在“全部”的第一页。
2020-03-18 11:00:32 +08:00
回复了 unii23i 创建的主题 职场话题 公司员工不服从安排怎么办?
@hooych #38 请问,老板让你上班时间进办公室**你不从,是不是不服从工作安排?只有劳动合同上写明的工作不干或干不了,才能无赔偿开除,而这劳动合同上写的是工种,对于程序员来说就是**开发。

@unii23i 你应该庆幸他们不服从你的安排。他们要是服从了,那你么公司会是什么样的呢,一个既非直属上司也非间接上司的人发个命令就无条件去遵从?那不就是个人都可以拿着鸡毛当令箭了吗?这样今天你压别人一头,明天别人就压你一头,最终整个公司死于乱发命令。还有你特么的真以为都服从你的安排就能推广出去了?你自己都说出来产品没人用的原因是产品太烂,那么不买水军光凭自己公司那么一点人就像强行推广出去?其实你这么做的原因并不是推广产品,而是“老板说社区内容都没有什么更新,责任怪到我头上”,你要真负责,应该是强行得罪整个技术部门,将“产品烂”直接告诉老板。
2020-03-18 09:48:23 +08:00
回复了 yyh0808 创建的主题 分享发现 关于招行 app 语音窃听
一说手机窃听,就有一堆技术帝来说“这不可能,太耗电了”,然而技术帝从来不列出详细的技术数据。

楼主这推测不准,受了“手机窃听”的先见结论的影响。这儿这确实有可能是通过语音分析做得定向广告,但不一定是通过手机获取的语音,也不一定是窃听的方式(窃听一切,人工或大数据分析后,再做后续处理)。

你在汉堡王吃饭,能听到你聊天的除了手机,还有汉堡王、投放在汉堡王的各种机器,以及更有可能的,刚好是业务员朋友的路人。
程序员不是谍报人员,不需要 24 小时监听数据,它只需要设置一个定向触发器,触发到之后就发广告。最近招行看到了风头在大力推广 E 招贷,完全可以设置一些触发推广 E 招待的触发器,比如“搜索了贷款”、“说了贷款”、“浏览了信用卡界面”等等,这些触发器就可以安装到前文所说的各种设备——手机麦克风、商场、商场的联网机器、业务员的朋友。对于手机来说,触发器是不需要 24 小时在线的,它每个半个小时听一次,外人很难发现。
团队必然重组,请准备接受二次面试,以及合理应对随后可能出现的“优化”
JavaScript 这个名字来自于网景(跟 Java 没半毛钱关系),但早期 JavaScript 的事实标准是两个,一个网景的 Javascript 一个微软的 Jscript。这些年下来,Javascript 的基础标准,从来都是网景 /火狐和微软这两家在做。实质上不是微软拿下了 js 语言的生态,是它一直都掌控着 js 的生态。
2020-03-17 15:07:08 +08:00
回复了 ybw 创建的主题 git 版本控制系统的合并操作,会引入新 bug 吗?
@ybw #15 git 这里,两个分支共同修改一个文件则冲突; svn、cvs 那里,两个分支(或者本地与服务器)统统修改一个文件且无法自动合并则冲突。有冲突并不一定会引起 bug,比如两个分支都修改了同一个文件但只修改了注释。没冲突也不表示不会引起 bug,比如 A 分支仅修改上层代码 B 分支修改了前者依赖的底层代码。
2020-03-17 15:01:15 +08:00
回复了 ybw 创建的主题 git 版本控制系统的合并操作,会引入新 bug 吗?
@aleung #12 URL 本身就带了它的定义——SCM ( Software Configuration Management,软件配置管理)。软件配置管理是软件工程学的正式名词,版本控制系统 VCS 算是俗名或早期名称,二者通常无须区分,但 Git 当中并没有版本号的概念,再叫它版本控制系统真得不合适。
2020-03-17 14:54:55 +08:00
回复了 yys1994 创建的主题 深圳 见过以转正答辩不通过为理由裁人的吗?这种公司真的恶心
@yys1994 #5 别仲裁了,直接按照“无劳动合同”投诉吧。最好还要找个懂法的人帮忙。
2020-03-17 14:27:22 +08:00
回复了 yys1994 创建的主题 深圳 见过以转正答辩不通过为理由裁人的吗?这种公司真的恶心
方便的话,把劳动合同脱敏后发一下吧。我怕你这合同签的是半年劳务协议。
2020-03-17 14:23:22 +08:00
回复了 ybw 创建的主题 git 版本控制系统的合并操作,会引入新 bug 吗?
会,几率跟版本控制系统本身无关。版本控制系统只是用来控制源代码的存储和协同修改的,跟 bug 唯一有的关系是“任何修改都可能引入 bug”。

要想不引入新 bug,靠的是测试和 review。

题外话,cvs、svn 是版本控制系统(人家名字中就带着 version ),但 git 就不再适合归入版本控制系统了。git 从名字到组成都没有 version 的概念,连顺序历史的概念都是人为加上去的。
2020-03-17 10:07:17 +08:00
回复了 Livid 创建的主题 全球工单系统 字节跳动的小伙伴请进
@awanabe #16 阿里的不用了吧,人家是真招人(并且没人理),看着置顶都没人回复,非常爽。
2020-03-16 15:46:00 +08:00
回复了 Delav 创建的主题 职场话题 国外找工作叫 [应聘] ,国内找工作叫 [求职]
我毕业时,“行业缺大量程序员”、“程序员的工作不好找”同时存在;男女比例 11:10 了,单身女士越来越多;国际原油降价了,国内油价还不变; 18 世纪爱尔兰大饥荒的时候,码头上还成船往不列颠运土豆:这些你是不是更不懂。

劳动力缺失,跟大量失业,并不冲突。
@speculatorA #8 如果你搜索个各种简历技巧的话,那么你就会发现,投简历,不管是网站投、邮箱投、还是线下投,如果不是当场拍板,就都是进简历库等待下次集中抽阅,并不会有人针对你这一次单独的投递做回复。实际上,若你收到了电话,那是人家抽阅之后对你感兴趣的主动访问,而不是对上次投递的回复。
2020-03-16 15:09:46 +08:00
回复了 mmqmyy 创建的主题 职场话题 关于离职的疑惑
如果你们公司有独立人力资源部的话,那这个猜测八九不离十:人力资源部独立,不会多事的辞退或劝退;部门人数是定员的,你不走就没法招新人; leader 想换个人,所以 leader 只能想法让你主动离职;如果 leader 没有成功劝退,他是会向人力资源部反馈的,但在名面向只会影响你的考核成绩进而堵死上升渠道,并不存在立马走人,连降薪都不会。

还是那句话,不要怂,也不要顶,更不要想 N+1。人力资源部不会趟这混水的,根本不可能辞退你;你要不走 leader 也弄不走你,但你不走就阻挡了他奋斗,他要么整死你要么整死自己。
“已读”,在绝大多数情况下,是一种毫无卵用的设计。
2020-03-16 14:42:07 +08:00
回复了 weishao666 创建的主题 问与答 请教关于 ER 图
关于 ER 建模,我建议你系统的看下这个博客系列: https://www.cnblogs.com/muchen/category/794749.html

另外 ER 图是一种表示法,一般都不会采用原始的陈氏表示法。你这个图上实体的属性在矩形内书写,还有*、1 这些,就与原始表示法不相同。上面那个博客上面用乌鸦脚表示多重性,也与原始表示法不相同。关于原始的陈氏表示法,你可以看这里: https://www.vertabelo.com/blog/chen-erd-notation/

还有,一些博客,以及一些画图工具、建模工具,尤其是一些数据库工具,会把 ER 模型跟数据库设计一同看待,那是认识上的一瓶不满半瓶咣当或者商业需要,千万不要上当。
2020-03-16 14:31:44 +08:00
回复了 weishao666 创建的主题 问与答 请教关于 ER 图
ER 图的线,只有两端有多重性和约束,中间是没有东西的。(有些图,会用线去表示关系,那么线中间就是关系的描述,但 ER 图是用菱形的框表示关系,线只是用来连图的,不是关系)。双框菱形代表的是识别关系不是弱实体,弱实体要用双框矩形表示。

你的 1、2、3 是关系的两端,并不是线的中间,代表的是多重性和约束。“蛋糕—配料”关系是一对多的关系,所以 1 那里是“*”(即 0..*,或者非强制、可多个),2 是这个关系的定义和描述,再右下是“1”(即 1..1,或者强制、单个),双框菱形表示 2 是识别关系,它额外点名了“配料”实体从属于“蛋糕”实体( ER 图的关系是没有方向的,需要自行判断)。上面虽然配料属于蛋糕,但配料本身不一定是弱实体,取决于你想不想让他独立,图上用得强实体,那么配料虽然属于蛋糕,但也是独立的。弱图上配料用了双框矩形点名时弱实体,那么配料就不是独立的,从而不会有 ingredid 这个属性。

“蛋糕—顾客”关系是名为“订单”的识别关系,图中没有“订单”实体。“蛋糕—顾客”的多重性是多对多,即两端都是“*”(非强制、可多个),3 就表示的这个。这个图是严格学术性情况下才这么画,现实中不会将订单这么严格的定义为关系,而是直接定义成实体,此时订单将换成矩形,同时订单—蛋糕、订单—客户之间分别多出两个多对一的菱形。

ER 图是概念模型,数据库表设计是逻辑模型或物理模型,两者之间不是一码事。你这个图上面,Contain (包含关系)是多对一关系,对应到逻辑模型中,可能是独立的表,也可能是 Ingredient 表的 cakeId、qty 两个列,具体哪个取决于设计者。Order 是多对多关系,对应到逻辑模型中就必然是独立的表。另外,如果 ER 图中把 Order 换成实体,逻辑模型设计是不变的。
1 ... 25  26  27  28  29  30  31  32  33  34 ... 153  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1572 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 40ms · UTC 16:59 · PVG 00:59 · LAX 08:59 · JFK 11:59
Developed with CodeLauncher
♥ Do have faith in what you're doing.