Everything you care about in one place
Follow feeds: blogs, news, RSS and more. An effortless way to read and digest content of your choice.
Get Feederxargin.com
No Headback
Get the latest updates from No Headback directly as they happen.
Follow now 51 followers
Latest posts
Last updated about 1 month ago
人类能力维度与AI可替代性分析
about 1 month ago
随着人工智能在2023-2025年的快速发展，我们亟需系统性、跨学科地审视人类各种能力维度，并评估哪些能力容易被AI取代，哪些仍是人类独有的优势。本报告参考认知科学、心理学、社会学、人类学、神经科学、哲学等领域的模型，构建了一个人类能力分类框架，对各维度能力的AI替代现状和未来进行深入分析。人类能力的分类框架人类能力是多维度的系统。传统上，心理学家将学习领域分为认知（智力）、情意（情感）和动作技巧三个域 (Three Domains of Learning - Cognitive, Affective, Psychomotor)。在此基础上，不同理论扩展出了更细致的分类。例如，加德纳提出的多元智能理论将人类智能分为八到九种相对独立的智能模块，包括语言、逻辑数学、音乐、空间、身体运动、人际交往、内省（自我认知）、自然观察和存在（哲学思考）等智能 (Multiple intelligence model...
中台 2023
about 2 years ago
眼看他起高楼，眼看他宴宾客，眼看他楼塌了。AI 浪潮之下，人的思考渐渐连机器都比不上，这些一直存在脑子里的知识应该都放出来也没什么关系了。我在 2019 年在某司从业期间，曾经写过一篇《中台的末路》，从一线工程师和架构师的视角来思考当前大公司内部的中台架构到底会碰到什么样的问题。在我离职之前，有一些问题已经有了明确的答案。有一些还没有，后续加入猫厂下公司也是为了验证我的困惑，在另外一个环境下看是否已经有人铺好前路，搭好路灯，为后来人指出了方向。业界一般把中台分为两个类型，数据中台和业务中台，前者主要指大数据、实时计算的技术栈封装，以及公司内的数据资产沉淀、管理和治理。这其中的数据治理需要与公司的业务场景结合进行设计，但数据中台中 80% 的技术其实和业务本身关联性没有那么大，目前各家公司的数据中台建设往往也都比较成功，将普通数据研发从复杂的数据基础设施复杂性中解放了出来，在《One SQL to Rule Them All》论文出现之后，经过了两三年的发展，实时计算在 90%...
给面试官一点小小的 gpt 震撼
about 2 years ago
ai 工具最近越来越越火了，在公司内给同事们简单做了个分享，有同事已经觉得可能晚上要睡不着觉了 orz。技术和工具日新月异，最近每一周感觉技术世界都在发生巨变，而还在那些传统岗位上的我们的工作，半年后，一年后，两年后，又有多少价值呢？虽然有些写代码的程序员还在嘴硬，坚持自己所做的事情做到“资深”，就不会被 ai 取代，可能还是太高估这个行业大多数人日常工作的含金量了。我个人认为不出两年，it 行业就会发生巨变。后面还会有具体的分享。从目前很多“大佬”的动作来看，大家都想在这一波浪潮中不落于人后，加入 aigc 创业的大军中去，不管他们的目的是沽名钓誉，还是真的想做点事情推动人类的生产力进步，还是要祝福他们。周末闲来无事，在曾经一个 Go 圈子里专攻面试的群里看到有人分享了这么个案例：嗯，放在两周前看到我会比较震撼。放在现在嘛，我动了动歪脑筋，既然 chatgpt 可以生成面试题，那么...
下一次工业革命近在眼前了
about 2 years ago
winter is coming去年的这个时候，IT 圈哀鸿遍野，吐槽技术红利消耗殆尽，所有公司都失去了新的增长点，程序员红利到头了。今年的这个时候，程序员的好日子确实进入倒计时了，只不过不像当初做预言的人想的那样，连他们自己的末日也在倒计时了。中国的互联网从业者并没有把 AI 当回事，这几年来对 AI 的看法是这种基于统计和传统神经网络的技术不足为惧，因为硬件的发展让老树发了一点新芽，套上强大的核弹厂芯片加一些修修补补的算法，能帮这些批着科技外皮的牛皮癣广告公司卖出更多的广告，能让信息茧房里的人看到更多他们喜欢的信息，奶头乐吸得不亦乐乎，让整个网民群体娱乐到死，普通人失去了研究的耐心和学习发展的能力，商业公司赚到了更多的钱，着实是 win-win 麻了。2022 年下半年，Github 的...
Google 用了十年的 subset 算法被换掉了
over 2 years ago
之前在这篇 subset 限制连接数量 里，简单总结了 SRE book 书里讲到的 subset 算法的基本原理和问题。 之前还在做 mesh 的时候，也曾经想把...
sarama producer hang 又一例
over 2 years ago
之前公司因为 aws 的 kafka 服务上的副本数配置不正确，所以在 aws 例行重启时会导致 producer hang，连锁导致消费断连，当时总结了一篇简单的文章：aws 上 kafka 服务更新导致断连一例公司内部写...
微服务税
over 2 years ago
现在稍微有一点规模的公司基本都上微服务了，后端工程师在大小公司打杂的话都会碰到因为是微服务，所以在做开发的时候：依赖太多，没有稳定的环境，服务跑不起来服务要走网络，稳定性问题难以解决上下游要解耦，每次上游做修改下游都会有故障各种各样奇形怪状的问题，每一个痛点都会涉及到不少相关的解决方案，比如环境问题，之前我分享过 https://tilt.dev/；稳定性问题，我们直接去看 Google 三步曲 https://sre.google/books/；上下游用队列解耦之后，上游的不稳定业务事件导致下游故障，有 data validation 平台和 schema registry 来缓解。我们这里还只是举了几个简单的例子，每一个问题都需要额外的努力来规避，对于那些正在迁移到微服务的公司来说，这些不过是一大堆问题里的九牛一毛。对于想要使用微服务的公司来说，需要了解微服务税的概念：It is...
平台到底有什么价值
over 2 years ago
不知不觉已经过了靠纯代码输出来做事情的阶段，很多时候做事情变成了说服别人做事情本身的价值，自己体力输出对于公司的贡献度已经越来越小了。作为一个架构师，需要能够帮助部门和公司走上正确的路线，避免无意义的内卷和消耗，以免让一线的开发心灰意冷无所成长最终提桶跑路。2017 年，美团在南京上线了打车业务，滴滴上下为之震惊。彼时滴滴在本土兼并收购，打跑了洋人对手 Uber，正是意气风发之时。又因为资本和老板之间良好关系的原因(CEO 们没少勾肩搭背吧)，滴滴的高管们曾经认为美团绝对不会涉足打车领域，所以美团的决策让整个公司从上到下都很震惊。O2O 业务在前期是笼络用户阶段，靠用户数量的增长为未来盈收的增长埋下种子，当业务达到一定规模，再以成本优势将用户对平台的依赖转化为平台的收益。用户增长的核心引擎就是公司内部的运营系统，早期运营是大多数互联网公司的边缘业务，在大多数公司内大家一听到运营，想到的都是 CRM 系统，体感就非常之 low，即使后来运营业务给自己贴上了 growth hacker 的标签，在外人看起来也并没有产生本质的不同。滴滴也不例外，传统的滴滴运营系统都是由业务驱动，业务向产品提供打法需求，产品进行汇总整理，再传达给研发部门，研发部门是纯粹的运营工具人，运营需要什么，研发就做什么。最多也就只是产品的纯粹翻译而已。滴滴和美团在南京短兵相接的时候，运营的弱点完全暴露出来了，双方都是财大气粗，准备了几亿现金要砸在优惠券上的，然而美团的活动往往能够在几天内全面开展，而滴滴的活动却需要半个月~一个月时间开发才能完成。美团只花了很短的时间，就吃下了南京市非常大的市场份额。与对手相比，滴滴有钱也花不出去，这时候大多数人才意识到，滴滴之前能够打败本土和外部竞争对手，可能只是运气好罢了。。美团经过多年各种场景的历练，内部已经形成了比较成熟的运营系统，能够借鉴历史经验，用自动化的运营工具来帮助公司开拓新的业务领域。其它 O2O...
aws 上 kafka 服务更新导致断连一例
over 2 years ago
公司内部写 kafka 的 consumer 和 producer 使用的是社区流行的 sarama 这个库，这个库应该 bug 挺多的，之前有云厂商建议用户不要使用该 lib...
为什么大公司讲的效率如此虚伪
almost 3 years ago
最近和一些前同事聊天，有些同事已经离开了大公司，一少部分还留在大公司里和年轻人们内卷。思来想去，我个人应该之后也不会去国内的大公司了(希望不是 flag)，有些阶段性的问题也是时候该有答案了。刚毕业的时候年轻的我曾经问了当时公司 mentor 两个问题，一是为什么明明活儿干完了到时间却不能下班；另一个是为什么企业要用这些虚无缥缈的工时来作为员工的工作态度来进行考核。当时的 mentor 自己也没想明白，他说大家都是这样的，你别搞特殊。这令我非常尴尬，学生时代我的考卷就没有在考试结束的时候交的，既然半小时、一小时就可以把这些事情搞定，为什么非得屁股粘板凳上陪着各位同学呼吸考场的脚臭味。企业里的潜规则却把按时下班也当成了搞特殊，让我想起了没人愿意当刺儿头的日本文化。不过日本的职场应该也不是十年前的样子了，还有这样的电视剧能上映：我们的主流文化时至今日依然鼓励奋斗而不是偷懒，连按时下班可能都会被划到不够奋斗的落后分子里，要以最后走出办公室为荣。上进奋斗并持续不断地加班再加班，哪怕整个社会已经陷入到生产过剩的经济危机里去。辛苦生产的牛奶，就倒掉？不说大环境，只说公司里真的有这么多事情可以做吗？从近十年的职业生涯来观察，显然没有那么多事。大企业依靠垄断、价格歧视和数据驱动的剥削让他们实现了躺着赚钱，即使组织臃肿，内耗严重，产品和研发人员像拉磨的驴，每天做着拧螺丝，拆螺丝再拧螺丝一样的自我感动但对企业毫无用处的工作，浪费再多的人力支出和白花花的银子，大企业依然有可观的利润空间。一些产品为了让一线的研发帮他去做毫无意义的需求，会跟你说：这个平台是 CTO/总裁/总监/部门一把手的需求这个平台公司内所有人都会用这个平台是我们公司级的战略项目信以为真的研发们，上线了以后发现日 pv = 1，时间喂狗，产品经理光速跑路，哑巴亏只能往肚子里咽。这样的故事每天都在很多巨头公司里上演，影响他们躺赚了么？如果有某个大公司的人跳出来跟你说他们很重视效率，你可别骗我了老哥。提高了效率能早下班吗？既然不能，那通过加班来提高的所谓人效只会让一线员工更累。而通过设计和工具提高的效率只会让一线员工显得工作不那么饱和，一点也不符合想要努力在大公司向上爬的人们的利益。我们不说生产工具的革命性进步，即使只是在业务内部跑通了配置化的平台，可能几十个人就会从天天加班变成无事可干。这让一线的管理者怎么去向老板要 HC 呢？一线领导期望的最佳状态是手下所有人忙得不可开交，最好把周末也全部奉献出来，营造一种欣欣向荣的假象，一边自我感动一边向老板要人。为了在效率根本没有提升的情况下向老板证明需要更多的人，这些企业的牛鬼蛇神们又琢磨出各种各样的研发效能指标，打工人为难打工人。举个例子，在不少大公司都会帮业务部门的工程师计算需求吞吐量和代码总行数，虽然有些公司会声称这些只是一个参考，不会计入考核。但实际上在考核季都是会将这些作为考核分数的一部分的。特别是想要让一些不太听话的员工排在后面，就会找找这名员工平常是不是在一些指标性的数据上有缺陷。如果我们有两个系统的话：其中一个系统每次有需求都需要开发两星期，周末加班其中一个系统所有需求都能在几分钟内点鼠标搞定，不需要写代码单纯的技术人员会觉得肯定是下面这个系统好，在给自己设定目标的时候，也希望最终出来的都是这样的项目和成果。但对于公司来说，你怎么实现根本不重要，公司会计算的只有成本而已，你通过自动化来实现的流程，和通过花钱养研发来手动操作，如果成本差不多，那对于公司来说就没有任何区别。追求自动化让自己轻松一些也只是研发人员的一厢情愿罢了。数据性的指标也不见得会被拿来做效率提升指导，大多数公司从研发这里统计出的数据被收集到管理者门户中，成为了管理者们...
怎样降低沟通成本(1)
almost 3 years ago
几十~几百人规模的小公司，业务、研发、产品、市场等等角色的沟通成本并不是特别高。在公司创业早期，一个人身兼数职，沟通成本就更低了。有事情，大家拉到会议室，简单学一下金字塔原理，碰到问题很快就能得到解决方案。游戏界有一个很经典的案例，早期从北方暴雪跳槽出来的几个人，都是会写代码的美工，他们只用了 12 个人，在很短的时间内以极高的效率做出了 torchlight 这个游戏，完成度很高，令人惊叹。公司扩张到千人时，沟通瓶颈就开始比较明显了，即使将所有人的 schedule 全部用会议塞满，还是难以快速有效地得到结论，所有人看起来都很忙，项目延期更是常事。大公司在和小公司在竞争的时候，同一起跑线的项目甚至会比小公司还慢，为什么会这样？很简单，随着规模的扩张，大多数人的大部分时间都被浪费掉了。可以从研发的视角来举一些例子：编码时间被无穷无尽的对齐会议，故障处理，日会，周会，双周会，月会挤压，只能在一天挤出两三小时来做主业公司的人员配比不合理，例如 PM 有很多，但 RD 却不多，产品经理迫于 KPI...
go-redis 和 redis server 版本错位导致的高延时问题一例
almost 3 years ago
公司内有多个 go-redis 的 client 和多种 redis cluster 版本，业务压测发现即使只访问 redis 的接口也可能会延迟达到秒级，非常反直觉。我们用不同版本的 go-redis 和不同版本的...