扎克伯克的裁员信 今天，我们不讨论裁员这件事本身，只说说扎克伯克的裁员信。 裁员信公开发在 Meta 官网，我建议大家读一下，里面有一些有意思的内容。  大部分的裁员信，都是假惺惺的例行公事，"由于市场形势的变化，我们不得不做出一个艰难的决定......"。但是，这封信不一样。 扎克伯克详细解释了，他对公司管理的想法，以及下一步的打算。如果你想了解硅谷巨头的内部情况，这封信可以提供不少信息。 首先，他直言不讳地说，上一次裁员的效果很好， 公司效率提高了。 "自从我们去年裁员以来，一个令人惊讶的结果是许多事情进展得更快了。回想起来，我低估了优先级较低的项目的间接成本。" 为什么员工少了，项目反而进展快了？ 扎克伯格的解释是，裁员使得公司大量取消低优先级的项目，集中资源到最重要的事情上面。 下面这段话，我认为非常精彩。 "人们很容易认为，只要一个项目产生的价值超过其直接成本，它就是正收益的。 但是，任何项目都需要一个主管，我们要么提拔一个工程师，要么从另一个项目挑选一个人，让其负责该项目。这两种情况都分散了人才，并且创造出了更多的管理层。 如果项目继续发展，整个团队也许分散到多个楼层或多个办公室，这让沟通变得更加困难。 我们还需要为项目配备更多的笔记本电脑和其他资源，这些更多的工程师还会导致雇佣更多的 IT 人员、HR 人员和招聘人员。 随着团队越来越大，效率不断降低，反应变迟钝了。它也许会与另一个团队的工作重叠，或者本应使用现有基础架构时却构建了一个定制系统。 总之，那些低优先级项目对公司重要性不大，却带来复杂的间接成本，很容易低估它们。" 他的结论就是，必须进一步取消不重要的项目，精简组织，继续裁员不可避免。 接着，他又说，效率低下还有两个重要原因：管理层级太多，团队太大。 （1）为了提高效率，必须减少管理层级，推行扁平化组织。 "众所周知，公司结构每增加一层，都会增加信息成本、决策延迟和风险规避，因为每层的经理向上一级发送请求时，通常都会减少一些可能导致风险的设计。" 减少管理层以后，多出来的管理人员必须加入项目开发。 "我们强制要求，大部分项目主管都必须同时是项目贡献者，并且团队内每个人都可以向上报告到每一个层级。" （2）尽量避免大团队，产品团队最好不超过10人。 "一般来说，我们不希望经理拥有超过10名直接下属。" 为了把团队变小，就需要剔除团队里面的非技术人员。 "很多团队聘请了许多工程以外领域的专家。这有助于构建更好的产品，但必须确保我们的公司的主要人员仍然是技术人员。" "我们会将产品团队主要聚焦在工程方面，其他领域的一些人员会被解雇，并且避免产品团队被来自其他团队的大量交互请求所淹没。" 总之，扎克伯格明白说了，Meta 接下来要做三件事----砍掉低优先级项目、减少管理层级、缩小团队----都会产生多余人员，所以需要进一步裁员。 我估计，其他互联网公司也会跟进，同样去做这三件事，所以行业裁员大概还会持续一段时间，就业形势可能要到今年下半年才会有所好转。 [本文转载](https://www.ruanyifeng.com/blog/2023/03/weekly-issue-247.html)

批量调整勤哲Excel服务器图片附件尺寸 批量调整勤哲Excel服务器图片附件尺寸 这是个顽疾 勤哲服务器及其不稳定 限制了附件大小 完全没卵用 导致产线员工随手一拍都是大片 全部存在数据库 有些一张图甚至14mb 一张问题单可以上传8张图 经常一张单30mb 服务器数据库不堪重负 如果存在本地文件夹内都好说 有很多工具可以批量调整 但是存在数据库.... 真是超级坑爹 可以自行以下sql语句 查看下附件体积 SELECT c.FullName AS 详细路径, a.ObjName AS 模板名称, ROUND( ISNULL( DATALENGTH(dbo.ES_CasePic.img) / 1048576.0, 0 ), 2 ) AS 附件大小MB FROM dbo.ES_Bo AS a LEFT OUTER JOIN dbo.ES_V_TmpClass AS c ON a.ClassId = c.ClassId LEFT OUTER JOIN dbo.ES_Tmp AS t ON a.ObjId = t.objId INNER JOIN dbo.ES_RepCase ON dbo.ES_RepCase.RtId = t.RtId INNER JOIN dbo.ES_CasePic ON dbo.ES_CasePic.RcId = dbo.ES_RepCase.rcId WHERE dbo.ES_CasePic.NFSFolder = '' ORDER BY 附件大小MB DESC; 好在现在有AI 写了个py脚本 批量调整图片分辨率 数据库图片附件表单从16.41gb降到1.45gb 直接减掉了15gb 整个数据库体积显著降低到33gb，原先51gb 压缩后5.96gb，原先20.4gb 我都佩服我自己 真牛逼  py代码是ai写的 已在我生产数据库执行验证无异常 如果不清楚代码什么意思 请自己去问ai 至于在其他服务器是否能执行 要看你的环境 执行前请做好备份工作 不对执行脚本带来的后果承担任何责任   隐藏内容，请前往内页查看详情

多数人做不到的道德，都是伪道德 孔夫子教育子贡，一切多数人做不到的道德，都是伪道德，一切伪道德都是恶道德。 伪道德之于家国百姓不仅无益，反而伤天害理，祸国殃民，贻害无穷  “孔夫子有一个得意弟子名叫子贡，他就是当今儒商的鼻祖，子贡善于经商，家产百万贯，富可敌国。 当时鲁国有一条律法，律法规定：凡是鲁国人在国外沦为奴隶的，如果有人能把他们赎出来的，那么可以到国库中报销赎金。” “子贡竟然这么有钱，富可敌国，还是儒商的鼻祖”妖女若男没有系统的读过书，并没有听过这个故事，她只是知道孔子确实有个弟子叫子贡，但是不知道子贡竟然这么有钱，竟然都有钱到了富可敌国的程度了。 “有一天，子贡在国外遇到了一个做奴隶的鲁国人，便花钱将他赎了下来，让他恢复自由。 等子贡回到鲁国后，拒绝收下鲁国国库报销金，表示自己有钱，自己承担这笔赎金即可，国库里的钱可以留着多解救一个在外为奴的鲁国人。” 李姝讲到这里停了一下，然后看向妖女若男，轻声向其询问道，“若男姑娘，你觉得子贡的这一做法怎么样？” 妖女若男在李姝话音刚落，便毫不犹豫的大加赞赏，毫不吝啬对子贡连连夸奖，“子贡不愧是孔圣人的得意门生，得了孔圣人的真传，真是一个高尚的人，一个有道德的人，一个大方无私的人，一个正人君子，所有人都应该向子贡学习，学习他这种乐于助人、不图回报的高尚精神。” 听了妖女若男的评价，朱平安的嘴角又扯的厉害了 喂，朱平安你什么意思？！ 妖女若男看到了朱平安的表情，忍不住瞪了朱平安一眼，这个男人真是色迷心窍，心也跟着变黑了，忘了他自己是一个寒门出身了 近朱者赤，近李煮黑! 妖女若男对朱平安用力的哼了一声，表示鄙视。 “若男姑娘还真是一片稚子赤诚之心。”李姝微微笑了笑，轻声说道。 一片稚子赤诚之心?! 意思是说我幼稚喽?! 妖女若男品味处了李姝言外之意，顿时不服了，挑眉扬声道，“少夫人，这话是什么意思?我说错了?难道说子贡做好事反而还做错了?! 子贡怎么可能会错呢，人家子贡用自己的钱做好事，还不求国库报销金，难道不是一个道德模范吗?! 如果此人此言此行都算错，那世上就没有好人了。“ 李姝微微笑了笑，“若男姑娘稍安勿躁。 当时子贡赎人，拒绝国库报销金自德为国情承担赎金负累后，周围人交口称赞，称赞子贡道德高尚，游扬子贡是一个惊慨大方不求回报的人，是答国的大善人……” “对嘛，这才是正常人的反应吗，不像某些人啊为富不仁.”妖女若男立马接声道。 “很快，孔夫子听说了子贡的所作所为后，情绪激动的找到子贡……” 李妹接着往下讲道。 “呵啊，肯定是孔夫人老怀大慰，激动的夸奖子贡，有他遗风，光耀师门。” 妖女若男自顾自的说道。 李姝摇了摇头，缓缓说道，“孔夫子找到了子贡，大骂子贡不止，骂子贡此举伤天害理，祸害了无数落难的鲁国同胞。” “啊?什么？！孔夫子他大骂子贡，他有病吧……”妖女若男闻言，吃惊的张大了嘴巴，禁不住为子贡打抱不平，愤慨痛斥孔夫子有病。 人家子贡自己出钱赎人，还不求回报，拒绝了国库的报销金，自愿替国家分担赎金，无论怎么看都是十足十的大好人一个，还是绝大多数人做不到的大好人，怎么孔夫子还大骂人家子贡! 还骂的那么狠!这么难听！ 骂人家子贡伤天害理，祸害无数落难的各国同胞?! 孔夫子他这是颠倒黑白，闭着眼睛，味着良心，给人家子贡泼脏水啊! “孔夫子是不是觉的子贡抢了他的风头，抢了他圣人的殊荣?!害怕子贡名气大过他？！ 还真是小气啊。怪不得有这么多人背后偷着骂孔夫子虚伪迂腐啊，还真是没有冤枉他， 从子贡这件事就可以看出来，孔夫子还真的是欠骂，道貌岸然，黑白不分，小肚鸡肠，虚伪无德，简直不配为人师表……” 妖女若易情绩激动不已，原先在她口中的孔圣人，成了她口诛笔伐的对象，被她一通输出，几乎成了反面典型，被送上了耻辱架。 “若男姑娘你误会孔夫子了。”李姝缓缓摇了摇头，轻声对妖女若男道。 “我误会了?怎么可能误会他，人家子贡好心做好事，惹他一顿劈头盖脸的臭骂，你说他是不是欠骂……”妖女若男兀自愤愤不平道。 继而妖女若男又想到了什么，警惕的看向李姝，一脸质疑道，“还是说少夫人欺负我若男读书少，故意编造了一个子虚鸟有的故事唬我呢?” 李姝一脸坦荡的和妖女若男对视，无奈又无语道，“我骗你干嘛，这个故事是《吕氏春秋》书中的记载，若男姑娘若是不信，我让琴儿去书房取《吕氏蠢秋》来，若男姑娘自己翻看便是。” “不用了，我相信少夫人。” 妖女若男摆了摆手，她闯荡江湖这么多年也不是白闯荡的，察言观色的能力绝非等闲所能及，从李妹的表情还有言语中看得上来，李妹没有骗她。 另外，刚才幼儿后蒙的打脸经历，她可不想再经历一番了，她又没有受喜倾向。 “少天人说我误会，我哪里误会姓孔的了? 人家子贡好心做好事，他凭什么骂人家伤天害理、祸喜落难在外的鲁国?!“ 妖女若男继续追问道。 “孔夫子骂了一顿子贡后，痛心疾首的教育他，说圣人所做的事情，是可以移风易俗，教导可施于老百姓，而非独适于自己的行为。 鲁国原先的律例规定，所求的是人民心中的'道德’，只要大家看见落难的同胞能生出恻隐之心，花钱赎回这个人，就完成了一件义举、善举， 事后国家会给他补偿和奖励，让行善的人不会受到损失，而且也能得到大家的赞扬，长此以往，愿意做善事的人就会越来越多，大家竞相做善事。” “你子贡赎人不向国家领取补偿奖励，固然让你赢得了更多赞扬，但是同样也拔高了大家对，道德”的要求。 有你这么一件事在先，往后，那些续回落难同胞的人去向国家领取补偿和奖励，可能不仅再也得不到大家的称赞， 甚至还会被国人所嘲笑、贵翼和唾弃。人们会贵问他们，为什么不能像你子贡那样不领取补偿奖励，为国幸减轻负担呢?!” “所以，长此以往，人们就会对落难的音国同胞视而不见，不愿意再解救他们了。 因为人们不像你子贡这样有钱如果他们赎人后去国库报销的话，反而会被人们朝笑、市骂和呼弃，那就只好视而不见了。 所以说你子贡比举伤无享理祸害了无数落难的各国同胞啊。“

Epson R-D1,爱普生旁轴相机 Epson R-D1,爱普生旁轴相机 妹子总是迟到 所以最近都不拍妹子了 周六也没有公交车回去 所以每周六下午都去扫街 找了朋友借了台相机 这台相机绝大多数都没见过的 爱普生的 R-D1 初代发布于2005年 到今年刚好20岁了 手动对焦 基线没莱卡长 小屏幕 CCD 没即时取景 没有连拍 内存卡最大支持2GB 耗电量巨大 一节电池约拍100张 需要随身带多张卡 需要随身带多节电池 600万像素 咸鱼售价大约1W 好容易收到快递了 上弦按不下快门 也不知道哪里的问题 放了几个钟，又自己好了！             

大数据已死 大数据已死 "大数据"这个词，大家想必耳熟能详。这是最大众化的 IT 词汇之一，全社会曾经都热衷于它。  百度指数显示，"大数据"从2011年开始进入搜索引擎，然后快速传播，在2017年～2019年之间达到顶峰。 那时，大家都认为，数据在未来将指数式增长，世界将被海量数据淹没。如何处理这些数据，就成为了关键问题。它决定了一个企业甚至一个国家在信息时代的竞争力。 于是，企业纷纷寻求大数据解决方案，出现了很多相关的招聘岗位，还都是高薪。高校也积极响应，有报道称，国内有600多所高校开设了"大数据专业"或"大数据学院"，其中包括北京大学、复旦大学这样的名校。  但是，十年过去了，大数据并没有成为发展的瓶颈，我们依然足以处理产生的所有数据，在可预见的将来也是如此。 预言中的大数据时代，看上去不仅没有来临，反而变得遥遥无期了。 "大数据"这个词的热度，也在不断降温，被提及次数变少了，招聘岗位也慢慢不见了。 与之相应的是，"大数据"这个技术领域，也进展甚微，没有诞生新的概念和理论，技术没有突破，很多方向都停滞不前。 比如，专为处理大数据而设计的 NoSQL 数据库，声势越来越小，陷入停滞，反而是传统的关系型数据库（SQLite、Postgres、MySQL）强劲增长，越发受欢迎。 这是怎么回事？  谷歌的大数据工程师乔丹·蒂加尼 （Jordan Tigani），最近直言不讳地说："大数据已死"。 他认为，大数据时代已经结束了，大数据的存储和分析，作为一个技术问题已经解决了。 用户已经不必担心数据大小了，再多的数据都不是问题。 他提出了"大数据已死"的6个理由，我觉得很有说服力，下面就跟大家分享。 （1）绝大多数企业到不了大数据级别。 企业的数据量往往不到 1TB，很多甚至不到 100GB。 假设一家中等规模的制造业公司，拥有1000个客户，每个客户每天产生一个订单，每个订单包含100个产品。这家公司一天产生的数据量，依然远远小于 1 MB。三年后，数据总量也只有 1 GB，达到 1 TB 需要几千年。 就算是大型互联网公司，大多数时候也到不了大数据级别。假设某个营销活动有100万用户参加，并且同一时间，该公司开展了几十个这样的营销活动，每天的数据量依然不足 1 GB，就算加上各种日志，可能也只有几个 GB，这跟大数据相差甚远。 （2）存储和计算正在分离。 大数据包含"数据存储"和"数据计算"两个方面，如果放在一个系统里面处理，确实很难。 但是，这两方面现在已经能够脱钩，变成两个独立系统，各自都能独立扩展。这意味着，"数据计算"不受"数据存储"（数据库大小）的限制，反之依然。 因此，大数据作为单一问题就不存在了，变成了海量存储和大型计算两个问题。 （3）没有新业务的情况下，数据是线性增长的， 即每天的新增数据与以前的数据结构相同。 以前的数据一旦写入数据库，通常就不再发生变化，也没有新的计算需求，相关计算在以前就完成了。这时只要对最近的新增数据进行单独计算，然后保存就可以了。你很少需要每天扫描一遍旧数据：那些数据一成不变，为什么要一遍一遍计算它们呢？ 因此，对于一家企业来说，"数据会指数式增长"这个假设并不成立。而且，数据计算的需求，其实比数据存储的需求小得多，因为老数据很少需要再次计算。 （4）人们看重的往往只是最近的数据。最频繁的查询是针对24小时内产生的数据，一周前的数据的查询可能性要低20倍，一个月前的历史数据只会偶尔被查询。 这意味着，大数据更像静态数据，而不完全是动态数据。既然以前的数据很少用到，那么就可以压缩保存。一个包含10年数据的表格，可能会达到 PB 级别，但是如果压缩保存历史数据，压缩后可能不到 50 GB。 （5）真正拥有大数据的公司，几乎从不查询全部数据。他们90%的查询涉及的数据少于 100 MB，涉及 TB 级别数据的查询非常少。 就算查询 TB 级别数据，查询性能的优先级往往并不高。等一个周末或几天才拿到结果，通常是可以接受的。 另外，大型数据集的查询非常昂贵。谷歌的 BigQuery 的 PB 级别查询报价是 5,000 美元，即使是大公司也不会经常使用。 （6）硬件的飞速发展，使得单台计算机的计算能力大增。 2004年，谷歌发表 MapReduce 论文时，单机的计算能力还比较弱，很多计算必须通过分布式完成。 2006年，AWS 推出了 EC2 云主机，你只能用到一个单核 CPU 和 2 GB 内存。今天，AWS 的标准实例具有64个内核和 256 GB 内存。如果愿意多花钱，还可以拿到445个内核和超过 24 TB 内存。 单机计算能力大大增强，意味着大数据的最大难点----分布式计算----即使被用到，困难程度也大大降低。 综上所述，结论就是：数据量已经不需要特别关注了，再也不必担心处理不了海量数据了。 大数据作为一个技术问题，已经解决了。 [转载](https://www.ruanyifeng.com/blog/2023/03/weekly-issue-244.html)