简单得很:
GirlFriend gf = (GirlFriend) new Object()
gf.setAge(20)
gf.setName("XuKun Cai")
gf.setGender(Gender.FEMALE)
gf.setHeight(170.0f)
gf.setWeight(50.0f)
gf.setLegLength(120.0f)
gf.setMaterial(Material.SILICONE_RUBBER)
……
可以去 ruby-china 社区的开源项目上去提 PR,自己实现的终归是最香的
我是匿名区总钻风,我也看不到真实用户,但是以网警的技术,还是很轻松的
后端设计上可能会有 bug,如果能摸到日志应该可以大致追踪到,如果哪天社区上市了,你们可以请四大来审计后端设计和管理员的行为
用 AI 做数据挖掘,这就触及到我的知识盲区了,我们以前就是配几个 sql,传入时间、版本号,拿 echarts 画几个图放到报告里,当然 Metabase 里面也会存一份~
AI 太疯魔了,惹不起~
单纯只有 bug 数据的话,最多叫数据挖掘、数据分析,跟 AI 扯不到关系
一旦出了问题,团队、领导、所有人对你的体感,那都是直线下降,你之前做的所有好事,就跟消失了一样,别人对你的印象,一提起来说的都是,这不是当时写出 xxx bug 的人吗?这还怎么在职场生存?脸都没了,项目好处也跟自己没关系了
你想太多了,谁都需要经验和教训的累积来进步,哪有一开始就完美的?出一次问题就否定全部?你是不是太过在意别人的看法,自我 CPU 太狠了点……easy!easy!
奈斯,鸡器学习很赞,一看就是练习了一坤年的技术,黑子哥真棒,啥都会,仰慕 ing~
背后开两枪
请不要在社区讨论破解问题~~
我给你们理一下这个争吵的过程,你们看看是不是很可笑,然后我晚些时间锁帖~
- 观点一:唯技术论是不对的,业务也很重要甚至更重要
- 观点二:技术是很重要的,卷技术是一条 “混出头” 的可行路线
压根争论的不是一个论点,二者都没毛病,你说你们吵毛线~~~
我看到你这么长的回复,再联想到你前面发的帖子说你连续几个月每天疯狂加班到深夜,心想必然是创业公司,晚上七点之前不用干活的
测试坚持唯技术论的人,最后的归属都会是搞培训班
你这句就是鬼扯了,我坚持了那么多年,最后的归属是失业——好在赋闲 2 年后凭着年前时摆弄相机的那点粗陋知识找到了个影像测评的工作~
30~45,取信 30,猎字当头,除以 1.5,实际 20K,我理解的没错吧各位大佬
来,说一下是哪个大厂?说出来让我们见识一下大厂的降本之道……
合情合理,完美操作,甲方圣明!
说真的,这世道有明明的一份功劳,我向来主张看中哪个面哪个,面不上再退而求其次面下一家,像明明这种凭借硬实力一下子拿 7 个 offer 的,给了那些用人单位更高的期望,希望人人都如 “我上次面的那个明明” 般强……而且多个明明叠加,搞的他们期望越来越高,但是现在出现了很多比明明更强或更年轻的人了,明明自己也遇到了困境,是不是明明自己造的孽呢?
明明三年前那会儿面试 11 个还能拿到 7 个 offer
坦白说第一眼看过去我觉得你在杠,仔细看了一下你发的内容,发现还是 GPT 在杠
额外说一句,用任何厂家的 AI,问问题的时候都不要带上倾向性甚至拉踩的方式,不然你得到的答案慢慢的、越来越接近你已经知道的信息,这是自己给自己创造信息茧房,而且这些 AI 很容易被 “投毒”,使用时更需小心。比如你要问:“格力空调比大金空调好在哪里”,不如问 “格力空调和大金空调各自有什么优缺点”。你预设了自己想要的答案,他们就会变成一种新的竞价排名工具……
这种为了杠而杠的问题,针对性太强了,GPT 显然在扮演理中客,强行否定……甚至为了杠而假定出对方说过某个错误言论,比如:
那种 “一旦用 LEFT JOIN,MySQL 就会被迫扫右表全部数据,而用 INNER JOIN 就能快速过滤只读少量数据” 的说法往往是过度简化甚至不准确的
“一旦用 LEFT JOIN,MySQL 就会被迫扫右表全部数据” 这句话谁说的呢?
在我看来,或许 GPT 连 “可能” 和 “一旦” 都理解不清楚,就没必要参与中文的逻辑解答了,要不你问问它 “INNER JOIN 和 LEFT JOIN 有什么区别”,看它怎么回答呢?
问一下 AI 就知道了,LEFT JOIN 的作用一般来说仅在于 返回左表所有行,右表部分无匹配,帖子里的场景 case_branch,起码会有个 main、master 或 base,必然会有匹配(如果没有,那就是数据结构问题了),为啥要用 LEFT JOIN?
在联表查询中,INNER JOIN 和 LEFT JOIN 的效率对比需结合具体场景分析,但通常 INNER JOIN 效率更高,原因如下:
示例:若左表有 1000 行,右表有 100 万行且无索引:
是什么样的魔鬼数据结构设计才会让你在 OLTP 应用里面敢随便用 left join 的
遇到这种问题我第一反应就是干死这种 sql,干不死就要重新设计数据结构
黑哥太霸道了,取关取关
你要不要去问问 kimi、ds、千问、文心它们这几个问题:
听听 AI 在放什么屁……再决定要不要用 AI 写 case
昊翔本人?