image from Wikipedia 八卦 随着孩子预产期临近，我还有一个重要的任务没有完成：给孩子起一个名字。 这本来是个随性的任务，但是由于上一辈笃信某个算命先生的姓名测试算法，让这个任务难度倍增。 我根据一些古文取了不少名字，但是最后都败在姓名测试上面：得分不高。得分不高老一辈就要有说辞， 我自己就是一个活生生案例，曾用名得分不高，中考被逼换了名字，改头换面重新做人。 我根据韵律取的名字几乎都败在算分数上面，我得琢磨一下其中奥秘，提高取名效率，避免再出现差错。 不少网站都提供姓名测试算命，我且先看看上面的得分，研究一下规律： ...
该系列三篇文章已经全部完成： 从 SQL Server 到 MySQL（一）：异构数据库迁移 - Log4D 从 SQL Server 到 MySQL（二）：在线迁移，空中换发动机 - Log4D 从 SQL Server 到 MySQL（三）：愚公移山 - 开源力量 - Log4D 我们用了两章文章 从 SQL Server 到 MySQL（一）：异构数据库迁移 / 从 SQL Server 到 MySQL（二）：在线迁移，空中换发动机 介绍我们遇到问题和解决方案。 不管是离线全量迁移还是在线无缝迁移， 核心 ETL 工具就是 yugong。 Yugong 是一个成熟工具， 在阿里巴巴去 IOE 行动中起了重要作用， 它与 Otter / Canal 都是阿里中间件团队出品。 它们三者各有分工： Yugong 设计目标是异构数据库迁移； Canal 设计用来解决 MySQL binlog 订阅和消费问题； Otter 则是在 Canal 之上，以准实时标准解决数据库同步问题。 Otter 配备了相对 yugong 更健壮管理工具、分布式协调工具， 从而长期稳定运行。Yugong 设计目标则是一次性迁移工作，偏 Job 类型。 当然 yugong 本身质量不错，长期运行也没问题。 我们有个产线小伙伴使用我们魔改后 yugong， 用来将数据从管理平台同步数据到用户前台，已经稳定跑了半年多了。 ...
该系列三篇文章已经全部完成： 从 SQL Server 到 MySQL（一）：异构数据库迁移 - Log4D 从 SQL Server 到 MySQL（二）：在线迁移，空中换发动机 - Log4D 从 SQL Server 到 MySQL（三）：愚公移山 - 开源力量 - Log4D （image via https://pixabay.com/en/military-stealth-bomber-refueling-602729/ ） 在上篇文章 从 SQL Server 到 MySQL （一）：异构数据库迁移 - Log4D 中，我们给大家介绍了从 SQL Server 到 MySQL 异构数据库迁移的基本问题和全量解决方案。 全量方案可以满足一部分场景的需求，但是这个方案仍然是有缺陷的： 迁移过程中需要停机，停机的时长和数据量相关。 对于核心业务来说，停机就意味着损失。 比如用户中心的服务，以它的数据量来使用全量方案，会导致迁移过程中停机若干个小时。 而一旦用户中心停止服务，几乎所有依赖于这个中央服务的系统都会停摆。 ...
（图片来自 The Dead Sea, Israel | One of the lowest, saltiest and unusu… | Flickr） 最近听团队老大的一个分享，介绍公司提倡的工程师的核心价值观，受益良多。 这也让我想起了一篇文章， Bruce F. Webster 在 2008 年写了一篇文章「The Wetware Crisis: the Dead Sea effect」， 翻译过来是「死海效应」。 Bruce 在文章中阐述了一个概念：一个团队可能陷入一种反模式，称之为死海效应。 死海是位于约旦的一个高盐分水域，由于水分被蒸发，这里的盐度是正常海水的 8 倍。 将水分比喻为高质量人才，盐分比喻为低质量人才。 水分容易被蒸发，而补入不足，盐分不容易蒸发日积月累，进而导致整个团队的人才质量劣化。 ...
该系列三篇文章已经全部完成： 从 SQL Server 到 MySQL（一）：异构数据库迁移 - Log4D 从 SQL Server 到 MySQL（二）：在线迁移，空中换发动机 - Log4D 从 SQL Server 到 MySQL（三）：愚公移山 - 开源力量 - Log4D 背景 沪江成立于 2001 年，作为较早期的教育学习网站， 当时技术选型范围并不大： Java 的版本是 1.2，C# 尚未诞生，MySQL 还没有被 Sun 收购， 版本号是 3.23。 工程师们选择了当时最合适的微软体系，并在日后的岁月里， 逐步从 ASP 过度到 .net，数据库也跟随 SQL Server 进行版本升级。 ...
（2017 年 2 月摄于瑞虹月亮湾） 我有两年没公开年终总结了，原因很简单：年终结果无法让自己满意， 生活持续呈线性发展。那今年为什么又要将总结发出来呢？ 并非是我的 2017 过得如何充实、有成就感，而是出于两个目的。 第一是我认识到 OKR 需要平和对待，我目前对自己的生活是缺乏完全掌控力的， 我无法既渴求爆炸性的增长，又期望在这一过程中低风险，我需要接受这种现状。 第二是曝光自己的目标，让回顾和计划透明化。 从社会心理学的角度上来看，公开的承诺有助于个体更努力地驱动目标的完成。 ...
最近和一位老朋友吃饭，他说他最近比较苦恼： 「开始有职业危机了，担心自己失去对工作的热情，似乎离油腻的中年人又进了一步」。 作为一名互联网工程师，我深知这个行业技术日新月异， 如果对工作都失去了兴趣，会将自己置于跟不上时代发展、自身得不到提升的危险境地； 从个人生活质量来看，工作占据了一天 1/3 ~ 2/3 的时间， 失去热情的工作会成为人生的桎梏，不是驾驭工作，而是被工作所奴役， 这会进而影响一个人的身心健康，得个抑郁症稀疏平常。 ...
本文首发在沪江技术学院公众号，小莞翻译，我做了校对。 由于微信公众号的封闭性，我担心未来文章不容易被发现。 为了避免沧海遗珠，特意转到这里。 英文原文：The USE Method。 USE 方法是一种能分析任何系统性能的方法论。 我们可以根据能帮助系统分析的结构化清单，来迅速的定位资源的瓶颈和错误所在。 它通常会先以列出问题为开始，然后再寻找适合的指标，而不是给你制定一些固定的指标， 然后让你按部就班的执行下去。 本页左侧下方，是我列出的，根据不同的操作系统（Linux、 Solaris 等） 衍生的 USE 方法列表。（译者注：可以参考原文链接） ...
原文作者：Nick Craver 翻译作者：罗晟 @luosheng & @alswl 原文地址：Nick Craver - HTTPS on Stack Overflow: The End of a Long Road 本文为原创翻译文章，已经获得原作者授权，转载请注明作者及出处。 本文首发在「沪江技术学院」公众号 今天，我们默认在 Stack Overflow 上部署了 HTTPS。目前所有的流量都将跳转到 https:// 上。与此同时，Google 链接也会在接下去的几周内更改。启用的过程本身只是举手之劳，但在此之前我们却花了好几年的时间。到目前为止，HTTPS 在我们所有的 Q&A 网站上都默认启用了。 ...
加入沪江不久，我就被扔到一个将集团 SQL Sever 的数据库迁移到 MySQL 的项目里， 同时伴随进行的还有 .net 系统迁移到 Java 系统。 在这个过程中我发现了一个很有趣的现象：历史遗留的 .net 项目中， 几乎所有的 SQL 中都会使用一个关键字：nolock。 这让我很困惑，nolock 的字面意思是对当前技术不使用锁技术，为什么要这样用呢？ 我找了一个范例如下： SELECT [id] FROM [dbo].[foos] WITH(nolock) WHERE aField = 42 AND bField = 1 作为横向支持工程师，开发工程师会问我：「数据库即将从 SQL Server 迁移到 MySQL，我们编码中还需要使用 nolock 么？ MySQL 里面对应的写法是什么？」。 我并没有 SQL Server 的生产环境使用经验，一时间无法回答。 于是课后做相关知识学习，这里就是这次学习的一点成果。 ...