12 月 03
范, 路OpenSource GitHub, GitLab, Gitlab功能, Gitlab安全, Gitlab开源版本, Gitlab总部, Gitlab数据, Gitlab服务器, Gitlab用户, Gitlab财报, Gitlab部署, Gitlab项目, GTLB, PostgreSQL, VIE企业, VIE架构, 中科星图, 中美制裁, 互联网企业, 交付, 代码传输, 代码发布, 代码安全, 代码审核, 代码版本, 企业代码管理, 低税制国家, 俄罗斯入侵乌克兰, 信创, 信创活动, 内资公司, 内部纠纷, 卫星控制, 合规认证, 团队协作, 国产操作系统, 国产数据库, 国产替代, 国产芯片, 国防特种地理信息系统, 外汇管控, 外资企业, 外资控股, 安全管理, 实体数汇报, 客户敏感信息, 开源版本, 开源软件, 律师, 微软, 敏感信息, 文档管理, 新加坡GitLab, 服务器部署, 本地化服务, 权限管理, 极狐GitLab, 气象生态, 爱尔兰, 版本控制, 用户代码, 监控系统, 研发团队, 程序员, 空间地理信息系统, 红杉基金, 纯内资公司, 纳斯达克上市公司, 美国技术, 美国政府, 联想基金, 航天测绘, 裁员, 认证考核, 财报, 软件工程, 软件开发管理, 违规合作, 间谍案, 集成构建, 韩国, 项目管理
极狐Gitlab间谍案到底是怎么一回事？大家好，欢迎收听老范讲故事的YouTube频道。今天咱们来讲一讲极狐的故事。事情呢是在11月28号曝光的，曝光人呢就是极狐Gitlab自己家的架构师，名字叫扬州。他呢主要曝光了几件事情。
第一个说公司是有外资背景的，而且外资控股比例超过50%。第一大股东是GitLab新加坡分公司，占股46%。而极狐GitLab呢一直宣传自己是国产软件，还去参加各种信创，也就是国产替代的活动，这肯定是欺诈。这个里边存在叫违规合作的问题，因为极狐接了一个叫中科星图的20万的单子，做了合作。中科星图干嘛的呢？做航天测绘以及卫星控制和运维、空间地理信息系统，包括国防特种地理信息系统，以及一些气象生态这样的业务。在这样的一个情况下，你一个外资公司去跟他合作，这事合适吗？
还有什么呢？中科星图是被美国列到实体名单里的，因为他肯定是做大量军用的东西嘛。你一个美国公司下边的子公司，向中科星图这样的一个被美国放到实体名单里的公司去提供这种技术合适吗？是不是应该受到处罚呢？他做了这样的一个举报。而且举报的时候呢还讲了说，这个Gitlab的后台有一套监控系统，它呢会秘密地搜集客户的敏感信息，包括你有多少个员工、开发了多少个项目、做了多少次编译、做了几次发布，这些呢都会向美国的服务器进行汇报。而且公司的负责人也会每个月或者每个季度向美国总部进行汇报，涉嫌泄密。
More
9 月 17
Luke FanAIGC AI Agent, AI 小模型, AI 模型, AIGC, API 调用, GPT-4o, GPT-5, GPT-o1, GPT5, Mini 版, Omni, OpenAI, Orin, Plus 用户, TOKEN 费用, Transformer 优化, 人工智能, 信息传递, 信息文献, 学习成本, 工程师, 幻觉产生, 数学能力, 显卡需求, 民间科学家, 深度思考, 猎户座, 研究报告, 社会稳定, 科学家, 科技分析, 科技创新, 科技创新力, 科技前沿, 科技前沿技术, 科技前瞻, 科技动态, 科技发展, 科技发展趋势, 科技变革, 科技大爆发, 科技展望, 科技工具, 科技市场, 科技应用, 科技影响, 科技影响力, 科技怪人, 科技投资, 科技报道, 科技挑战, 科技探索, 科技新闻, 科技更新, 科技未来, 科技未来展望, 科技机遇, 科技潜力, 科技热点, 科技热点话题, 科技研究, 科技突破, 科技筛选, 科技融资, 科技观察, 科技评测, 科技评论, 科技资源, 科技资讯, 科技趋势, 科技进步, 科技预测, 科技领域, 科研工具, 程序员, 编程效率, 编程测试, 编程能力, 自动驾驶, 英伟达, 草莓模型, 计算机科学, 语言生成, 金字塔状态, 预览版, 高成本, 高效提示词
大家好，欢迎收听老范讲故事的 YouTube 频道。今天咱们来讲 GPT O1 发布，科技大爆发应该会到来。草莓模型终于发布了。今天我太太还问我说，这个模型发布了，对于你们这些科技圈的人来说，算是意料之外，还是算意料之中？这个事情直接把我问在那了。
其实，每一个人都希望赶快把草莓模型发出来。但是 OpenAI 从今年年初开始公布 Sora 到现在，他吹的牛有点太多了。到现在为止，这是我们真正见到的能够用的产品。虽然 GPT4O 也是能用，但完整的 GPT4O 其实到目前为止，一直没有彻底开放出来。而这个 O1 上来直接就开放了，今天早上凌晨 3 点突然上线，哐往那一挂，大家愿意用的都可以去用了。我自己也去用去了。他呢，也换了一个名字，叫 GPT-O1。所以呢，这就不是 GPT5。
未来可能会走两条路，一个是继续走这种直接进行语言生成的，而 O1 这条路，走的是深度思考，要去反思一个问题，要深思熟虑以后才去回答。所以他有可能两个路要分开走，而且两个模型可能会相互配合着使用。
More
6 月 05
Luke FanAIGC, 老范讲给儿子的IT课程 AI, 个性化, 个性化服务, 人工智能, 商业, 基础原理, 大模型, 学习路径, 学生指导, 工程思考, 工程能力, 应用开发, 批判精神, 技术发展, 教育, 数字化, 数字时代, 数据结构, 未来趋势, 标准化, 沟通协作, 用户需求, 社会人文, 程序员, 编程语言, 职业发展, 自定义软件, 计算机教育, 计算机科学, 软件价值, 软件工程, 软件开发, 软件开发成本, 逻辑思维, 逻辑思考, 重复使用, 需求顾问, 高等教育
大家好，欢迎收听“老范讲故事”YouTube频道。今天，咱们来讲一讲AI时代，现在学计算机还来得及吗？啊，首先要跟大家讲说，这个内容是怎么来的。呃，儿子要成人礼了，也是马上要高考了，太太给了我一个任务，让我给儿子写一封信。所以呢，我就前面录了一个视频，是给儿子的一封信。这个里面呢，有一部分就是讲AI时代，学计算机应该怎么学的。现在呢，我把这一部分摘出来，单独跟大家聊一下。
首先呢，要讲一下我的父母跟我太太的父母，在我们两个人选择大学专业的时候，跟我们说的话。我父母两个呢，都是学机械的——机械制造、机械设计、机械原理。我太太的父母呢，应该都是学电子工程的。啊，当我去高考的时候呢，我的父母跟我讲说：“不要去学机械啊，去学计算机吧。”为什么呢？说学机械这事儿啊，太辛苦太累，需要去工厂，需要跟这些设备打交道，太累了。他说学计算机这事儿啊，虽然也挺累的，但是你好歹是在空调的机房里呆着呀，你跟这个在工厂里的人比起来，你要好很多了。当然，我自己也比较喜欢，这是大前提。
我太太的父母呢，在他高考的时候说：“学电子太累了啊，你要不停地学新东西，电子元器件啊，电子的各种设备啊，不停地更新换代，这事儿实在太累了。”
More
5 月 21
Luke Fan阿里巴巴的故事 2024年5月14日, BAT, CG, Chandry, Excel, KPI, 一财报道, 上市, 上海, 下线, 不能失速, 严苛, 举报, 互联网, 互联网公司, 互联网公司原罪, 互联网公司腐败, 互联网大厂, 互联网巨头, 互联网腐败, 京东, 人性, 人性之恶, 企业文化, 作弊, 公关, 内部监控, 内部管理, 内部贪腐, 凡事件, 分赃不均, 刘强东, 反腐, 合伙人, 商家贿赂, 坠机, 基层, 外卖员, 夜店, 大公司病, 天猫, 天猫旗舰店, 太嚣张, 失速, 奇葩方式, 字节跳动, 季报, 安勇, 审批, 审计, 年报, 店小二, 开除, 张勇, 扭曲, 投放, 抖音, 拼多多, 捞店铺, 掩盖, 撞枪口, 数据库, 文化认同感, 新兴互联网公司, 新兴公司, 机器, 机器管理, 李彦宏, 杭州, 杭州警方, 比价, 民营企业, 法制在线, 法制报道, 流量, 流量控制, 游戏公司, 漏洞, 猎豹, 电商平台, 程序员, 站错队, 算法, 管理方式, 结果导向, 美团, 老板魅力, 老牌公司, 职业经理人, 肖子, 腐败, 螺丝钉, 裁员, 规章制度, 财务管理系统, 财报, 贪污, 贪腐, 跑冒滴漏, 运营人员, 运营成本, 道德, 都市, 都市传说, 酒吧, 阿里, 阿里国际, 阿里小二, 阿里巴巴, 阿里店小二, 阿里月饼事件, 降本增效, 雷军, 飞机, 马云, 马化腾
阿里店小二的贪腐案
一年间，竟有阿里员工贪污了9,200万人民币。首先，这并非新近事件，而是一个陈年旧案，发生在2020年至2021年之间。最近，由于央视《法制在线》在2024年5月14日的重提，以及第一财经于次日的报道，此事再次成为公众关注的焦点。这相当于各大国家媒体又将此事搬上了台面。
据杭州警方透露，近期侦破了一起涉及民营企业内部贪腐的案件。一名在杭州某电商平台担任基础运营岗位的员工，在短短一年内，因收受贿赂高达9,200多万元而被曝光。可想而知，在杭州，能有如此收受贿赂能力的，非阿里莫属。
这起事件仍在持续发酵，人们议论纷纷，惊讶于何人能在一年内“赚”到上亿，而且他只是被称为“店小二”——天猫店小二。正如警方通报中所称，这是一位基础岗位的运营人员，如何能涉及如此巨额的款项？此人姓王，负责阿里天猫家具类官方旗舰店的入驻审批，专司商家进店事宜。
More
1 月 07
Luke Fan杂谈, 随笔 框架, 程序员
随着社会的进步，高楼大厦林立于市区，社会分工也越来越详细了。不论是游船还是后面的大厦，都不是一个人、一个团队、一个公司，甚至是一个行业可以完成的。越来越多的标准件被应用到了这些东西的建造和运维之中。
同样，随着软件应用的规模不断的扩大，一个人或一个团队从头开始编写完整的程序已经变得越来越难了，而且这样做也非常的不经济。于是有一种东西就进入了程序员们的世界，那就是框架，各种各样的框架。
框架通常是一个很庞大的代码库，由一个公司或一些团队完成。使用特定的语言编写，可以在特定的领域中解决一定的问题。其他程序员使用这些框架，在框架相应的领域中，可以更简单的，更直观的解决和处理该框架所涵盖的问题。
框架设计的目的，通常有这么几点：
对复杂的底层进行封装，使得这一部分可以完全对程序员透明，程序员可以通过这些框架，直接使用底层的功能，而不需要了解底层的细节。
对复杂的业务逻辑进行封装，使得程序员可以使用更加接近自然语言的方式，来构建全新的业务逻辑，满足复杂的企业需求。
对一些容易出错的内容进行封装，让程序员能够按照特定的规范来调用其他的模块、或使不同程序员或团队写出来的代码可以更好的协同工作。
对于不同工种与工序进行划分，便于不同的工种和工序之间进行并行工作和协作。尽可能的对参与同一项目的不同工种和工序进行分割和隔离。使得这些工种和工序，可以独立的进行修改和调整，尽量少的影响到其他的相关环节。对于现在的应用来说，美工和程序员之间的这种协调就是非常常见的，而且这也让很多团队感到非常的头疼。很多框架就是解决类似问题的，可以让美工修改资源的时候，尽量不影响代码。让程序员修改的代码的时候也可以尽可能少的影响美工的工作。另外一个经常和程序员打交道的就是策划了，如果让程序去适应复杂多变的策划，也是很多程序框架试图解决的问题。
对同一类型或有相同使用背景的应用进行规范化，并利于这些应用进行统一的展示、安装、卸载以及信息通讯的框架，很多portal框架都是这么做的，这种框架应用的成功体现就是AppStore了。
既然框架这么好，能够解决这么多的问题。那么为什么本文的标题不是“框架之美”，而是“程序员与框架之间的战斗”呢？
通常一个程序员接触框架的过程是这样的：
接到一个困难的工作，使用原来的手段无法完成或很难在可以接受的时间内，提交满足需要的成果。于是必须使用一个框架了。为了框架而框架的情况是存在的，但是这里不推荐那么做。这个时候，程序员会去网上搜索，去搜寻各种信息，并在浩如烟海的框架中选择一个他认为最适合的框架来使用。悲剧的是，有时候这种选择并不是由技术人员，在清醒的状态下做出的，J2EE就是这么一个看上去很美的错误。
选择了框架之后，并不是马上就能够开始干活儿的，框架虽然对很多东西进行了封装，使其尽可能的变得简单。但不可否认，通常的框架本身也还是很复杂的。要想熟练的使用框架来完成所需要的工作，还是需要有一定的学习过程的。
在学习之后，就是使用框架来解决问题。这个时候，可能就会发现，当初选择的框架并不那么好用，并不是那么贴近自己的应用需要。这种情况通常是由四方面的原因造成的：
第一：对于框架的学习不够彻底和深入，那些适合本次应用的功能没有被发现，以现在框架的复杂程度、同类框架的数量和文档的粗糙程度来看，这很正常；
第二：设计框架的人和当前的程序员在编程习惯方面不是非常相符，使用框架的程序员又非常的固执，众所周知，程序员通常都是很固执的，甚至有些还很偏执；
第三：框架设计的时候，所考虑的覆盖范围，和现在所需要实现的应用有些偏差，或者是框架已经跟不上时代的进步，不能适应当前的情况了；
第四：程序员过于的完美主义，这也是程序员，特别是成功程序员比较典型的一种性格特征。
有些应用还有可能会因为使用了过度的框架和不合适的框架，而变得面目全非。
于是下一个阶段就是对框架进行改造。对于商业框架就提意见，希望能够得到修改。对于开源框架，那就简单了，直接可以进行修改。
然后，程序员会继续使用这些用起来越来越得心应手的框架，去做各种合适或者不合适的事情。经过了不断的修改和调整之后，一个个历史悠久的、有生命力的框架也都向着越来越全面化的方向发展。这个时候，他们就忘记了，框架其实是为了实现某些特定功能而设计的。
即使再全能的框架，也总有一些不适合去实现的功能。不过程序员们是执着的，当他们对一个框架的喜好程度发展到热爱甚至是痴迷的时候，他们是不理智的，甚至是不可理喻的。爱情使人变成白痴，这句话用在这里也是合适的。毕竟一个框架，日夜陪伴着程序员，程序员们学习和了解框架；使用框架攻克难关，完成任务；这些框架还会为程序员做出各种各样的改变，以实用程序员的习惯。这种过程其实和恋爱中的男女相处的过程很像的，那么程序员对于框架产生出一些超出友谊的感情也是很正常的。于是就会出现这样一种情况，一些程序员会使用他们所钟爱的框架，去完成一些该框架本身完全不适合的工作。
即使这看起来很不协调，但是程序员们也会坚持去这样做的。
最终，很多程序员会选择抛弃框架，或者不得不抛弃以前那些笨重的框架，重新去选择一些轻量级的东西，甚至干脆自己开发框架来使用。但是这些框架最终也逃脱不了上面那些框架的命运，会变得越来越庞大的，最终再被抛弃。毕竟维护一个框架的成本也是很高的。有些公司由于一个框架而得到了成功，最终也由于那个框架，走向了消亡。框架是很难与时俱进的，通常情况下，框架是只能做加法，很难做减法的。毕竟框架的升级是需要考虑向下兼容性问题的，如果从框架中做了减法，那么就意味着以前的应用，在升级使用新框架的时候，有一部分无法正常工作。
现在还有很多高级程序员，更喜欢裸奔。
这就是战斗了，裸奔和框架之间的战斗。框架和框架之间的战斗。那么程序员们到底应该如何面对框架呢？特别是在自己也开发了框架，或者至少是自己对现已有框架非常熟悉，并且熟悉到分不清自我的情况下，应该如何面对其他框架呢？
建议大家，在需要的时候，选择需要的框架。框架的使用也是有成本的，请选择成本最优的方式，来判断是否需要使用框架，以及应该使用什么样的框架。如果是一个周期很长，即使使用了框架也需要进行大量工作的任务，那么就千万不要去选择那些不了解、不熟悉或学习成本很高的框架。因为，所有框架都有一个特性，那就是易学难精。如果有些框架不需要很深入的了解，就能够很好的完成当前的应用，那么请毫不犹豫的选择使用这些框架。毕竟这样可以使应用的开发周期极大的缩短。尽量不要去选择那些包打天下、包治百病的框架，这种东西通常是很臃肿的，而且这种东西一旦遇到了不擅长的领域，会让大家非常难以取舍。不要去选择那些很难进行调整和修改的框架，这种东西很可能会因为一点点的不契合，就让你不得不放弃它，但这个时候随着框架一起被放弃掉的，很可能是整个团队在该框架上付出的巨大努力和海量代码。在选择框架的时候，首先要确定这个框架还有人维护，还有很多人在用，网上有足够多的资源，能够帮助你和你的团队度过开始的学习期，也能够在遇到困难的时候，很容易的找到网上的先辈们来帮忙。如果团队中的大部分人都熟悉一个框架，那么即使现在的框架并不是完全适合当前的需要，最好也是直接在现有框架的基础上进行小的调整，而不是去找个新的来。实际上完全符合需要的情况基本上是不存在的。当然，如果实在是相差太远的话，那也就不要太坚持，有时候换一个会更好一些的。
程序员与框架之间的战斗，归根结底还是一个度的把握问题。到底能不能将这个度把握好，做出正确的判断和取舍，决定了程序员是不是能够战胜框架，征服框架，并和框架一起再去战胜应用。希望以后大家能够在和框架的战斗中得到美妙的享受。就像男人和女人的战斗一样。
RSS