Latest

痛风带来的思考

昨晚一罐冰啤酒下去,睡觉时就感觉脚踝隐隐发作,果然早上起床直接下不来地。跟崴脚的感觉十分相似,无法行走,只能坐在一起上滑动,公司上班也去不了了,呆呆得躺在家里,下午疼痛感加剧,整个心思都在左脚的疼痛上,没有其他任何多余的精力去关注其他事情,而此刻的阳台,乃最美人间四月天,春日的微风吹拂着阳台的花儿,温暖的阳光抛洒下来,一切都如此惬意,而我却无心欣赏。 人在健康时,生活中有好多问题,但人在不健康时,生活中只剩一个问题。 我对这句话的理解更深刻了。人是健忘的,在疫情期间、在手术期间,这种感悟其实已经很深刻了,但是病情好转之后,人还是会被日常的琐碎、工作的烦扰搅乱心绪,没有专注的去享受生活本身的美好。 幸福的秘密在于,去享受我们所拥有的,而不是顽固的去追求所没有拥有的。阳光、草木、微风,都是幸福的玩意儿,应尽情的享受。 再等两天,脚完全恢复好了,身体健健康康后,我要以更轻盈的姿态去生活,不纠结他人的看法,不执着别人的认可,关注自己的能力,享受拥有的生后。 还有一个反省,针对咖啡、酒、烟,

By 李浩

设计模式之命令模式

命令模式将“请求”封装成对象,以便使用不同的请求、队列或者日志来参数化其他对象,命令模式也支持可撤销的操作。 来解析这个定义: 1. “将一个请求封装为一个对象”,请求原本是一个方法,现在要封装成一个对象,说明要新增类来完成。 2. “可以用不同的请求对客户进行参数化”,说明是将命令对象作为参数进行传递。 3. “队列”说明需要维护命令多个命令的列表队列。 4. “撤销”说明有命令对象有undo撤销方法。 命令模式在设计模式中,算是一个比较不好理解的模式,很重要的原因是不清楚设计意图,不清楚不用这个模式前有何问题,这个模式带了哪些好处,能解决什么问题。 上一篇状态模式中,看到了状态模式抽离的是状态(属性),向上提成状态对象。有了这个基础,再来理解命令模式就相对简单了。命令模式抽离的是行为(方法),向上提成命令对象。 两者都通过“对象化”来解耦和扩展系统,但解决的问题不同: * 状态模式:处理对象内部状态驱动的行为变化。 * 命令模式:处理行为请求的封装与调度。 💡智能家居遥控器,假设我们有一个智能家居遥控器,可以控制 灯(Light) 和

By 李浩

设计模式之状态模式

状态模式允许对象在内部状态改变时改变它的行为,对象看起来好像修改了它的类。 来解析这个定义: 1. “内部状态”表明对象内部有一个属性来表示状态。 2. “内部状态改变时改变它的行为,对象看起来好像修改了它的类”说明状态改变后对象的行为发生了非常大的变化,不像是同一类的行为。 从目前的分析中似乎无法推导出状态模式的类图结构。 从实际的例子出来,来看看状态模式是如何演进而来。 💡我们有一个文档审批系统,文档有以下状态和转换: 1. 草稿(Draft) → 提交 → 待审批(PendingReview) 2. 待审批 → 批准 → 已发布(Published) 3. 待审批 → 拒绝 → 草稿 4. 已发布 → 撤回 → 草稿 从直觉出发,会使用条件语句实现需求逻辑。 public class Document { private String state = "DRAFT"; // 初始状态为草稿 public void submit(

By 李浩

设计模式之代理模式

代理模式为另一个对象提供一个替身或占位符以控制对这个对象的访问。 解析这个定义: 1. “替身”表明在客户端看来,代理类与被代理类是同一类别,对客户端来说看上去没什么区别,依然能够满足诉求。如此可以看出代理类与被代理类来自同一个超类。 2. “控制对这个对象的访问”,能够控制访问,说明前提是能够访问,才能在访问之前做这个限制,即代理持有对真实对象的引用(或能创建它)。 当然可能会质疑,用继承的方式不是也能完成目标吗,用代理类去继承被代理类,然后重写方法,加入控制逻辑。但这违背了"组合优于继承"原则,代理类与被代理类强耦合。 💡我们要开发一个图片查看器,需求如下: 1. 图片加载开销大(从磁盘或网络加载耗时),希望首次显示时才加载(延迟加载)。 2. 某些图片需要权限校验,只有授权用户才能查看。 3. 客户端代码应统一接口,无需关心是直接加载图片还是通过代理。 // 1. 抽象接口(Subject) interface Image { void display(); } // 2. 真实对象(RealSubject)

By 李浩

设计模式之组合模式

组合模式是一种结构型设计模式,它允许你将对象组合成树形结构来表示“部分-整体”的层次关系,使得客户端可以统一处理单个对象和组合对象,而无需关心具体的对象类型。 解析这个定义: 1. “结构型”&“层次关系”,说明此模式针对的对象结构十分典型,对象间的关系有明显的结构特征。 2. “树形结构”,说明此模式就是针对树形结构的对象关系。 3. “部分-整体”,说明组合对象包含了单个对象。 4. “客户端可以统一处理”,客户端可以不关心对象是属于单个对象还是组合对象,表明单个对象和组合对象有相同的超类,而且实现了相同的接口。 在设计业务场景中,有部分整体关系,成树形结构的,有许多,比如: * 文件 vs 文件夹 * 员工 vs 部门 * 评论 vs 回复 从对定义的解析,到树形结构的实现,可以推导出组合模式的结构图。 但,组合模式的关键点,不在于结构图,而在于真正理解这个模式解决的问题,已经为什么要如此设计。 组合模式的核心本质之一,是将递归逻辑从客户端转移到“组合对象”内部。

By 李浩

设计模式之迭代器模式

迭代器模式提供一种方法顺序访问一个聚合对象中的各个元素,而又不暴露其内部的表示。 解析这个定义: 1. “聚合对象”,表示对象中有数组、集合、字典等数据类型属性。 2. “顺序访问”,表示模式需提供一个遍历的方式。 3. “不暴露其内部的表示”,表明不想让客户端知道太多内部细节。 综合来看,此模式的设计意图非常明确,将聚合对象的遍历访问职责封装抽离出来。 直接抛出 Iterator 接口和 next()、hasNext() 方法有些“上帝视角”了,让我们抛开预设的实现,从零开始推导如何设计这个“抽离聚合对象访问”的模式,一步步探索最终如何自然演化到经典的迭代器结构。 第一步:明确核心问题 假设我们有一个聚合对象(比如一个自定义集合 MyCollection),内部用数组存储数据。现在需要让外部能遍历它的元素,但不允许直接暴露内部数组。如何设计? 初始代码(暴露内部实现,不符合封装原则): class MyCollection { private String[] data = {"A"

By 李浩

设计模式之模板方法模式

模板方法模式定义一个操作中的算法骨架,而将某些步骤延迟到子类中实现。模板方法使得子类可以在不改变算法结构的情况下,重新定义算法的某些特定步骤。 解析这个定义: 1. “算法骨架”,表明是定好了调用多个方法调用的框架顺序。 2. “某些步骤延迟到子类”,延迟到子类说明框架由超类定义,“某些步骤”表明只是部分交由子类自定义,而还有一部分是由超类已经定义好了,由此可以表明超类必须是抽象类,而非接口,“某些步骤”相应的就是抽象方法。 💡假设我们有一个电商平台的支付系统,支付流程通常包含以下固定步骤:验证支付参数、调用支付网关、记录支付日志、通知支付结果,其中,第2步"调用支付网关"因支付方式不同而实现不同,其他步骤则可以复用。 // 抽象支付类 - 定义支付流程模板 public abstract class PaymentProcessor { // 模板方法(final防止子类修改流程) public final void processPayment(double amount, String orderId) { validate

By 李浩

设计模式之外观模式

外观模式提供了一个统一的接口,用来访问子系统中的一群接口。外观定义了一个高层接口,让子系统更容易使用。 解析这个定义: 1. “统一的接口,用来访问子系统中的一群接口”,如果不这么做之前,当多个客户端时,每个客户端都需要实现调用一群接口的逻辑,实现重复且复杂。且客户端耦合每个子系统的具体实现,不符合开闭原则。用一个统一接口封装一群接口,客户端只需要依赖一个类的一个接口即可。 2. “高层接口”,说明外观类是在子系统之上,这是一个架构结构上的变化。 💡现代计算机的启动过程涉及多个硬件组件(如CPU、内存、硬盘等)的协同工作,每个组件都有自己的初始化逻辑。 没有外观模式时的实现: // 子系统类(与之前相同) class CPU { public void start() { System.out.println("CPU启动"); } } class Memory { public void load() { System.out.println("内存加载&

By 李浩

设计模式之适配器模式

适配器模式将一个类的接口,转换成客户期待的另一个接口。适配器让原本接口不兼容的类可以合作无间。 解析这个定义: 1. 客户端依赖的接口TargetInterface,无法用现有的类adaptee实现,需要增加一个新类adapter来包装实现,但客户对此应透明,感知不到,如何才能感知不到,就需要adapter类继承或实现客户端依赖的类或接口,这样依赖抽象编程,就可以在子类去完成适配转换。 2. 适配类adapter要能实现客户要求的能力,如何做到,有两种方式,一种是直接关联一个adaptee对象,调用对象的目标方法;另一种方式是直接通过继承,自动拥有父类的目标方法。这两种实现方式称为对象适配器和类适配器。对象适配器思维更加自然,更为常用,特别是对于需要适配多个类接口时,一些语言是不支持多重继承的,无法用类适配器完成,只能应用对象适配器。 对象适配器还是类适配器,只是如何获取被适配对象的目标功能的两种不同方式而已,很多人常常采用强记的方式学习设计模式,死记类图,其实完全没有必要,更重要的事,理解模式本身的意图本质,和实现目标的思考过程。类图会依据继承或实现画法发生变化,往往让初学

By 李浩

从郎咸平批评认知看职场祛魅

郎咸平在回复一个提问“月入五千和月入五万”在认知上有什么差别时,本以为他会从认知维度高谈阔论来论证,结果却是对提问者好不委婉的训斥,他说: “你们和送外卖的在认知上没什么区别,在我看来没有区别,你们一样啥也不懂,唯一的区别是你过了哪条线,才有了参与的机会。恰好你还干得不错,可能是这个因素,也可能是那个因素,就是综合原因,才走到了现在”。 这句话乍一听有点刺耳,甚至带着点精英主义的傲慢,但仔细琢磨,却戳中了职场和社会竞争里最隐秘的真相——很多时候,你需要先拿到上桌门票,才有机会参与游戏。 在职场中,要进行祛魅职场,那些“上桌的人”,未必比你强,只是比你早一步摸到了入口。 我花了很长时间才想明白一件事:那些坐在高位的人,那些在会议上侃侃而谈的“专家”,那些手握资源、头衔光鲜的“成功者”,其实并没有想象中那么不可企及。他们未必比我聪明,未必比我更懂业务,甚至未必比我更努力——他们只是比我早一步摸到了某个入口,或者恰好踩中了某个契机。 这个认知让我彻底放下了对“权威”的盲目敬畏。我开始明白,职场和社会竞争的本质,不是能力的绝对比拼,而是一场关于“规则、

By 李浩

从《长安的荔枝》看职场

《长安的荔枝》是马伯庸以"一骑红尘妃子笑"为背景创作的历史小说,通过小人物李善德运送鲜荔枝的曲折经历,折射出许多值得深思的职场生存法则。结合这个故事,谈谈几点职场体会: 1. "领导一句话,下属跑断腿"的职场现实 李善德接到"从岭南运鲜荔枝到长安"这个不可能任务时,深刻展现了职场中"目标自上而下传导,执行压力由基层承担"的常态。体会是: * 上级的决策往往不考虑执行细节 * 中层需要将模糊目标转化为可执行方案 * 执行层要在资源有限的情况下创造奇迹 2. "流程合规"与"结果导向"的博弈 李善德在遭遇衙门推诿时悟到:"做官之道,其实就三句话:和光同尘,雨露均沾,花花轿子众人抬。"这揭示了职场潜规则: * 过分坚持原则可能寸步难行(

By 李浩

设计模式之单例模式

单例模式确保一个类只有一个实例,并提供一个全局访问点。 咋一看这个定义,先解决一个疑惑,什么时候需要保证类只有一个实例。在实际生产场景中,有许多这样的实例,大多出于两个目的,防止资源浪费和保证数据一致性。比如常见的数据库连接池、线程池、日志记录器、缓存实例、配置信息实例等通常只需要一个实例来管理资源,能够节省开销,避免多实例带来的数据不一致。 明确了实际用处后,再来解析定义: 1. “确保一个类只有一个实例”,类是如何实例化的,通过调用构造函数,谁调动构造函数谁就能创建实例,确保只有一个实例,就是要控制构造函数被调用的权限,防止外部代码通过构造函数或其他方式创建多个实例。 1. 私有化构造函数:将类的构造函数设为私有(或受保护),禁止外部直接调用构造函数创建实例。构造函数私有了,构造出的唯一实例也必须是本类自身维护了。 2. 控制实例化过程:在类内部管理实例的创建,确保只有一个实例存在。 2. “全局访问点”,为了让外部代码能够方便地获取这个唯一的实例,使用静态方法即可。 💡日志记录器(Logger),应用程序的多个模块需要记录日志。日志记录器应该是全局唯

By 李浩

设计模式

设计模式之工厂模式

工厂方法模式定义了创建对象的接口,但由子类决定要实例化的类是哪一个。工厂方法让类把实例化推迟到子类。 来解析这个定义: 1. “创建对象”这个点非常关键,表明了工厂模式的职责就是为了创建对象的,而不是干其他委托、代理什么的。同时也将创建对象这个职责从Client迁移出去了。 2. “子类决定要实例化的类是哪一个”,说明创建对象的方法被子类继承,而这个方法的返回值是目标类,并且隐含着一个更重要的点,父类中定义的这个方法的返回值一定是一个目标抽象类,而子类返回是目标具体类。 3. “实例化推迟到子类”,表明是在客户端调用时,通过选用不同的子类,来决定目标对象的具体类。 学习设计模式,一个关键的自我校验,是能够自己给自己出题,构建场景,并通过目标设计模式来解决。 💡假设我们有一个汽车制造系统,系统需要生产不同类型的汽车(如电动车、燃油车)。我们可以使用工厂方法模式来实现这个系统,使得不同类型的汽车由不同的工厂子类来创建。 // 1. 定义抽象产品类(汽车) abstract class Car { public abstract void drive(); } /

By 李浩

设计模式

设计模式之装饰者模式

装饰者模式动态地将责任附加到对象上。若要扩展功能,装饰者提供了比继承更有弹性的方案。 来解析这个定义: 1. “动态”指的在运行时进行的,而不是在编译时,也即客户端调用时可以临时决定增加责任到对象上。 2. “责任附加”意味着可以在不修改原有对象的情况下,增加新的行为或功能。 3. “比继承更有弹性”,说明使用的是组合而不是继承,通过组合可以在运行时动态地添加或移除功能。弹性意味可以组合多个能力,而不需要创建大量子类。 装饰者最重要的核心是装饰者和被装饰者来自于同一个超类。相比较于策略模式、观察者模式,难以理解一点,并不是一个自然就能想到的结构。我们从源头来看看它的设计脉络。 💡假设我们正在开发一个文档编辑器,用户可以在编辑器中输入文本,并对文本应用各种格式(如加粗、斜体、下划线等)。编辑器需要支持以下功能:用户可以动态地为文本添加或移除格式,格式可以叠加(例如,文本可以同时加粗和斜体)。 先来一个自然能想到的简单实现: // Text 类 public class PlainText { private String content;

By 李浩

设计模式

设计模式之观察者模式

观察者模式定义了对象之间的一对多依赖,这样一来,当一个对象改变状态时,它的所有依赖者都会收到并自动更新。 来解析这个定义: 1. “一对多依赖”说明被观察的主题需要维护一个观察者列表,当然要提供加入列表和从列表删除的能力,可以命名为attach、detach方法,来实现观察者的添加和移除。 2. “对象改变状态”说明了被观察者有一个被关注的参数属性。 3. “一个对象改变状态时,它的所有依赖者都会收到并自动更新”说明当主题发生变化时,依赖者有一个方法可以被触发执行更新操作,所谓“自动”指依赖者不必要主动调用,而是被动调用,因此依赖者需要有一个被调用的方法,可以命名为update。 4. 结合关联抽象的经验,所有依赖者应该有一个共同的抽象,给到主题维护 可以初步得到以下类图。 学习设计模式,一个关键的自我校验,是能够自己给自己出题,构建场景,并通过目标设计模式来解决。 💡新闻订阅(RSS 订阅)是一个日常生活中经常碰到的场景,这个场景中新闻发布者(NewsPublisher) 是被观察者(Subject),而 订阅者(Subscriber) 是观察者(Observer

By 李浩

设计模式

设计模式之策略模式

策略模式定义了算法簇,分别封装起来,让它们之间可以相互替换,此模式让算法的变化独立于使用算法的客户。 来解析这个定义,“算法簇”&“相互替换”代表了是一组相同目的算法,肯定是利用多态能力实现。脑海中,下述的类图就出来了。 “变化独立于使用算法的客户”,这句话的意思是,使用这些算法的客户端代码不需要因为算法的变化而修改自身,什么意思,如何能做到改变算法而不修改自身,那就是客户端代码只依赖于算法的抽象(接口),而不是具体的实现。 通过类图,可以清晰的看到两者的区别。 学习设计模式,一个关键的自我校验,是能够自己给自己出题,构建场景,并通过目标设计模式来解决。 💡以支付场景来举例,具体的支付方式有支付宝和微信,需要支持用户在实际付款时动态切换。 1. 定义算法接口:定义一个 PaymentStrategy 接口,表示支付方式的抽象。 public interface PaymentStrategy { void pay(int amount); } 2. 实现具体算法:AlipayStrategy 和 WechatPayStrategy 分别实现 Payment

By 李浩

设计模式

设计模式开篇

首先应该对要讨论的设计模式主题进行约束,是面向对象编程的设计模式,针对于非面向对象编程,如函数式编程、过程式编程,也有相应的设计模式。 明确了是面向对象编程,那么所有的设计套路都是基于面向对象编程的特性,封装、抽象、继承、多态四大特性就是设计模式的基础,各种模式都是利用了这些基础能力来巧妙设计的,如果没有编程语言自身的能力支持,就谈不上设计模式了。 因此,这四大特性应该真正做到理解,而非死记硬背,理解之后,后续讲到每一种设计思路时,才会有清晰的脉络,模式不是被突发的设计出来的,而是经过经验演进而来。 封装,将同一类的属性、方法统一装在一个类中,强调聚类效果。 抽象,在具体类别上再设计一层,能够更高的抽象,定义通用的接口或抽象类,隐藏具体的实现细节,提供更通用的视图。 继承,通过类的层次化结构实现代码复用,子类可以扩展或修改父类的行为,减少代码重复。 多态,通过父类的接口调用子类的具体实现,使得代码能够以一种通用的方式处理不同的对象,提高代码的通用性和灵活性。 这些特性共同构成了面向对象编程的核心,是设计模式的基石。 上图中,可以看到是整个设计模式的一个最小结构,其他的模式都是

By 李浩

认知客厅

事以密成语以泄败

大家常常会在励志短视频中看到这样一句话,在事情做成之前对谁都不要说,包括最亲密的人。而与这句话相同意思的警句就是“事以密成语以泄败”。 这句话出自《韩非子》的《说难》篇,更多的侧重于政治及军事上,对信息保密的重要信,信息的泄漏可能会导致计划失败甚至灾祸。 对于现代社会的年轻人来说,更多的用于表达内心的某项个人成长计划、事业规划,比如在年初立下今年flag,热血上头要三个月掌握某项技能等,而非政治或军事上的含义。 那为什么会说在立个人计划时,也最好遵循此条行事准则呢。初一听会觉得挺有道理,做事情需要沉稳,提早说出来的人一般城府不足,定力不够,在成事概率上会降低许多。再者,话提早说出来就像煮饭提前揭锅,导致饭不熟,这是一个很容易理解的联想。 但这些解释还是在科学性上不够令人信服,大多是经验层面的总结,城府、定力、联想均是,这样就容易让人半信半疑,半信半疑就是不信,对某一认知,不是嘴上说出来就是掌握了,最终必须是通过行为实践上来体现。 知行合一,从“知”到“行”,其实中间还有一个十分关键的点,就是“信”,是发自内心的相信,半信半疑不行,

By 李浩

AI 小径

利用神经网络拟合一元二次方程

我们这次要拟合的关系是一个一元二次方程 目标 * 理解参数初始化对于模型效果的重要影响。 * 学习模型训练过程中,如何通过观察损失值相应的调整学习率、epoch大小。 数据构建 这次我们在准备数据的时候,就将数据进行划分好,总训练集100个,训练集90个,测试集10个。 # 生成准备y = x^2 + 2x + 1数据,共100个点,并按9:1的比例划分为训练集和测试集,并保存到CSV文件 ​ import numpy as np ​ from sklearn.model_selection import train_test_split ​ # 生成输入数据 x = np.linspace(-10, 10, 100) # 在[-10, 10]范围内生成100个均匀分布的点 ​ # 生成目标输出数据 y = x**2 + 2 * x

By 李浩

AI 小径

利用神经网络拟合一元线性方程

在现代人工智能技术中,神经网络通常被应用于复杂的非线性问题,如图像分类、语音识别和自然语言处理。然而,即便是简单的数学关系,像一元线性方程(y = ax + b) 的拟合,对于理解神经网络的基本原理、训练过程及其局限性会是很好的学习案例。 本文将探索如何利用神经网络来拟合这样一个简单的线性方程。我们将从零开始搭建一个基础网络,通过逐步训练,观察网络如何学习到输入与输出之间的线性关系。通过这个简单的示例,我们不仅可以验证神经网络的学习能力,还可以揭示一些训练过程中的常见挑战和优化技巧。 选择拟合的目标方程是: 目标 * 对可视化探索、模型构建、模型训练、模型测试有一个全程直观了解。 * 观察学习率、epoch调整对结果训练结果带来的影响。 数据构建 先来手动制作一批训练数据,以便为神经网络提供可用于拟合的样本数据。可以快速编写一个小脚本,生成 100 对 (x, y) 数据点,并将其保存在 train.csv 文件中。我们选择了一元线性方程 y = ax + b 的形式,后续构建神经网络及训练的目标是,通过训练逐步学习到系数 a

By 李浩

随笔小亭

企业挣钱跟小区店铺有类似逻辑

今天在填明年海外部门预算,以往都是敷衍了事,没有在意,这次专门看了具体条目,以及金额数量,才发现预算金额如此庞大,再加上idc成本,人员成本,场地费,税务,剩下的就没多少来。一直以为挣了好多好多,结果算上来净利润还是在百分之三十左右,虽然说对比其他行业来说,已经是一个非常不错的水平了,但对于之前没有详细算过账的感觉来说,一下就打破模糊的偏差认知了。 这个利润率,也是公司坚持投入了好多年,才逐步打平以至营收的。 具体办企业与小商店在底层逻辑上有哪些共同点呢。 一,最后的利润,都是钱经过层层漏斗,漏到最后能留下来的,才是最后到口袋的。哪一个环节没有做好控制,都容易入不敷出。每个环节的成本控制,都不可忽视。对于负责人或老板来说,对每个环节的成本支出必须做到了然于胸。 二,外部合作必不可少,不管是企业还是小商店,都只是经济环节中的某一环,都会有上下游合作方,对于软件公司来说,云平台、支付渠道、投流平台等都会涉及到与其他企业的利益分配。对于小商店来说,进货商、场地租金、营收工具等都需要花钱解决,商店本身只负责末端售卖。大家都是整条产业链中的一环,参与进来才是最重要的。 三,都会有成本,

By 李浩

随笔小亭

好的故事创意是否不会枯竭

似乎好久没有看到十分精彩的电影了,新出的电影观影过程中几乎就能才到后续的发展,总会感觉似曾相识或过于老套,引发了一个思考 - 好的故事创意是否不会枯竭。 如果不会枯竭,说明创意是一个永不会灌满的大水池,想不出创意只是能力问题,创意的点还无穷无尽。如何论证呢,无法论证,但是能计算,何解? 创意也可以分解为创意点的组合,将人类有史以来所有的故事放在一起,进行分解,可以提取出不同维度的要点,并且每个要点都会是可枚举的,即便是还未被创作出来的,其要点数量也会是可枚举的,可枚举的要点排列组合在一起,就会是一个有限数量大小。 如此看来,整个池子是一个固定数量,前面的创意点相对容易挖掘,越到后面,越难挖掘出来,想必这就是电影越来越难以创新的原因了,已挖掘的创意点多了,后续创意需要避开现有点才能被称为创意。 站在人的维度,看的电影越多,后续能触动到你的点就越少了。

By 李浩

随笔小亭

是什么在支撑这个民族

经常在一些局上,听公司上位者侃侃而谈,他们在社会发展的浪潮中,随着企业上市,成功的实现财富自由,应该来说,会对国家、社会、民族会心存感激,但从他们的话语中,鲜有如此论调,更多的是冷嘲热讽,谈话内容多是滑雪、潜水、旅游、大餐、出入境携款、移民等话题,对于国家经济、政策、环境,鲜有积极话语,更别说感激之类,这些多少令我有些差异。 他们对国内信息,多半是不信,而是从自认为更客观的外媒中去获取。发出的声音也多半对国内抨击的。 给我一种强烈的感觉,一群精致的利己主义精英。 改革开放四十多年,整个社会价值观都被绑在以金钱唯一锚定物的评价体系中,所有人一致的向钱看,没钱的自惭形秽,物质生活不如人,谈家国、谈情怀、谈文化会缺少底气,有钱的更关心如何赚更多钱。 成长的过程中,都会被教得圆滑、世故,有错吗,也并不是,做事情避免不了与人打交道,就需要尽可能团结一切能团结的人,避免树敌,在不违背大原则的前提下,圆滑世故换个角度来看,也是照顾对方的感情,

By 李浩

雷军在参访中多次提到他是一个极度专注的人

花了几个小时雷总在小米汽车发布之后接受的访谈,在谈话过程中,他多次说到自己不是一个投机者,而是一个坚定的长期主义者,做事情十分认真,极度专注。 聊到了小米决定开始做汽车时,董事会只提了一个要求,雷军必须亲自带队,而不能是找一个代理人来干,这是投资人对他无比的信任,事实证明,他们的判断是正确的。人,才是最重要的。 在访谈中有很多点令我印象深刻。 一,他说他是一个做事很认真,极度专注的人。认真、极度专注,在做事的过程中,会产生心流,产生的内啡肽是一种更高级的满足感,懂得了很多道理,只是第一步,这一步很重要,驱散心魔,让自己不会被后悔、内耗、焦虑、嫉妒等情绪裹挟,精力不被内耗,只把精力投入到事情本身,这是认知提升的过程,是修炼的过程,是“知”的阶段。下面就需要去“行”,这才是更重要的一步,可以半知而行成功的,但绝不能知而半行而成功的。去做事,去极致专注的做事。 二,要做对的事情,“站在风口上,猪都可以飞起来”

By 李浩