知乎上看到一个热帖，我觉得很有意思，叫做“为什么有些大公司技术弱爆了？”。我刚看到标题的时候，先入为主和刻板偏见了一下，正如同第一个回答一样，我皱了皱眉头，产生了对题主的鄙视之情；但是很快，读完帖子以后，我却立场明确地站到题主一边了。正如同里面有位回答：看题目以为是题主傻逼，看了正文发现真的是公司傻逼。上面这种情况其实发生的概率挺低的，但是我觉得这回是真的发生了。但是令我感到遗憾的是，各式各样的回答里面，大部分居然都跳出来“教育”题主，表态这个世界就不是完美的，表态要妥协要接受这样的事实，要无奈地咽下这个现实的苦果。这个大面积出现的观点，太不正常了吧？比如这样的话：写好代码是程序员的节操。抱歉，节操多少钱一斤，北京三环商品房多少钱一平？有的问题实在不是能够三言两语回答的，尤其是当面对整个行业的现实的时候，但是，可以很明确的是，当一个项目代码写烂掉的时候，这个项目也活不久了。好吧，还是就事论事，下面就贴过来，然后逐一分析其中的内容。说说为什么大致上题主没问题，有问题的是这家公司，这个项目组。=================================今年年初，到一家互联网公司实习，该公司是国内行业龙头。不过技术和管理方面，却弱爆了。那里的程序员，每天都在看邮件，查问题工单。这些问题，多半是他们设计不当，造成的。>> 这就是所谓的operation的工作，大多情况下很 ...继续阅读 (61)

经常用到一些命令，还总是忘掉的，就简单列在这里。总是现查也挺麻烦的。Linux：top mem consumer: sudo ps -aux | sort -k4nr | head -5 or top, then press Mconnection number: netstat -an | grep ESTABLISHED | wc –lprocess number: ps -ef | wc -lthreads of a process: ps uH p <pid> | wc -l.tar: tar -xvf archive.tar and tar -cvf archive.tar file1.tar.gz: tar -cvfz archive.tar.gz dir1 and tar -xvfz archive.tar.gz.zip: zip -r archive.zip ./folder and unzip archive.zip -d ./empty a file: sudo cat /dev/nullcapture all the output and run in the background： bb > /tmp/a.txt 2>&1 &list the latest changed files: ls -lht | ...继续阅读 (54)

偶然想到的这个话题，工程师做工程是一方面，而作为单纯的程序员，总是充满对于纯粹的追求。最近又负责了一个使用Angular的项目，我们知道最近Angular很火，其中一个重要原因就是它给前端开发带来的变革，第一次发现可以让以前如此恼人的变量绑定消失掉。以往变量绑定的语句放在附属于页面的一个js片段（文件）里面，颇有些无奈的意思，如果把它视为展现层面的东西，显得很不直观（声明式编程才是最直观的方式），而且让这一层变得啰嗦；而如果把它视为下面一层的东西，这又让逻辑代码变得不纯粹——凭什么要让逻辑代码去了解哪个dom叫什么id？于是Angular来了，引入了$Scope这代表上下文的东西，变量绑定替解决了（之前介绍过Angular的变量绑定和依赖注入），这个问题迎刃而解了，在复杂性不很高的情况下，性能问题不成为主要矛盾。它带来的收益明显更大。还有一个很常见的例子是常挂在程序员嘴边的单一职责原则，我觉得这大概是软件设计最重要的一条原则，就做一件事，把一件事做好。延展开去说，解耦和抽象是设计的核心艺术，但是所谓的解耦，目标也不正是把“不纯粹”的东西隔离开么？再延展开去，关于软件系统的分层，一样是围绕着“纯粹性”展开的，某一层都有自己需要了解的客户，也都有自己不应该关心的内容，例如业务层就不要了解数据源的知识，而数据层要通用到不具备业务逻辑。到了更宽泛的工程领域，纯粹依然作为目标在指引对于质量的 ...继续阅读 (48)

“不要重新发明轮子”是总是可以听到的话，在评判一个设计的时候，总是听到这样的话。但是凡是不绝对，而对于这句话来说，很多情况下，都是错误的。我甚至都不能说出“大多数情况下不要重新发明轮子”这样的话，因为具体问题，实在没法用大多数还是少部分来概括。重用轮子有什么好处？省代码；轮子已经经过千锤百炼，质量有保障；轮子功能在逐步更新中，可以看到未来的获益。但是，也有一些情况让我无法重用轮子。第一种情况，我只需要一点沙土，我不需要整座大山。比如，我只需要一个StringUtil.isEmpty这样的方法，判断字符串是否为空串或者null，如果引入Apache Common Lib当然可以解决问题，但是我需要么？需要一个简化的系统，这也是很常见的场景。第二种情况，dependency hell。这种情况主要是考虑到目标库的体积过大，或者依赖包太多，或者存在潜在的包依赖的冲突问题。比如我的项目需要开源包A，但是A依赖于库B的1.0版本，而我现在的项目直接依赖于库B的2.0版本，那么怎么解决B的冲突问题，就会很头疼。第三种情况，现有的轮子设计不好，想改进，发现却不易扩展。这种情况也很常见，如果对于源码的修改是便捷、合法且合适的话当然最好了，要不然，兴许会自己实现一套。第四种情况，发明轮子是一种相当的乐趣，而且，我要拿这个乐趣来吸引“有追求”的工程师。这不是说笑，就身边的事实来说，我见过好多team都 ...继续阅读 (71)

已经从加州归来一周多，本来不想写游记了。但是前几天整理照片的时候发现，有趣的东西还是有一些的，那就写一些文字吧。大致的行程：四天。第一天在三番市区，人文线，并夜登双子峰；第二天沿号称最美公路的一号公路南下，经过Santa Cruz，直到十七迈；第三天休息半天，然后前往世界最大的人工公园——金门公园，傍晚去金门大桥；第四天在硅谷的101公路沿线转悠，去了Facebook和Google等几家IT公司，还有斯坦福大学。Presidio公园我们停靠了两个景点，一个是沙漠和海滩结合起来的Baker Beach；一个是Crissy Field，湖+海湾的组合，可以望得到恶魔岛。去渔人码头闲逛和午饭。这里可以购物，还可以欣赏码头水景，亦有舰船展出。只是停车费不便宜，租个车一天才十几刀，但是停车费一个小时就九刀。轮渡前往Alcatraz Island——就是传说中的恶魔岛，以前是美国著名的监狱，重犯要犯关押在此，其中一个原因是处于海湾中，即便有囚犯能够越狱，也难以最终逃脱。历史上确实有人越狱并且下落不明，是否成功越狱，至今颇有争议。最终这个恶魔岛还是关闭了，一大原因是维护费用巨大，开销不起，如今只是供有人参观游览和各色鸟气息的小岛而已了。另外，推荐一个老片，根据恶魔岛故事改编的电影《The Rock》。站在岛上遥望就是繁荣的三番市区，正因为如此，在这座岛上的囚犯，心理落差的折磨想必是无比强烈。&n ...继续阅读 (62)

下面这些文字来自我在知乎的回答：“在真实工作中的编程是怎么样的，与学校里有什么不同？”。入行愉快。首先，一言以蔽之，用两个字来概括，就是“残酷”，但是，好在是加引号的。有的不但残酷，还很无奈；有的则是在残酷的同时，还很有趣。搞工程和学校里的象牙塔大不相同，这也许老早就知道，但是绝对不是七八年前我想象的模样。你可以把它当成我没睡醒的呓语，也可以当成我喝多的胡话，或者是心情太差的时候写的吐槽檄文。反正，它们就在那里，事实就在那里。总的来说，学校里面编程，或者在工作之余编程，是很有趣的，没有manager给你各种压力，也没有各种大神（比如TMP、PM、SE等等我都搞不清楚干嘛的职位）给你指点江山，你可以自己爱咋弄咋弄。当然，没有了这些“残酷”的痛苦，你没法进化，没法超脱，没法升华。就从一毕业开始的荒唐的面试说起吧。国内的公司问的更杂一些，知识性的问题也问，有时我反而觉得更务实。而外企则很喜欢考察“能力”，我加引号是因为他们觉得他们在考察能力，实际却不见得。因为他们只是在考察80%的算法+数据结构，以及一点点系统设计，一点点扯淡能力，再顺道看看颜值如何啊，八字合不合啊，星座属相啥的而已。因此，这其中前80%东西都是可以准备的。而应试，恰恰是中国人最擅长的东西。我记得有朋友在我的blog里面回复道，特别鄙视刷算法题和面算法题这样的做法。我想，我可以和你“同鄙视”的，但可惜我没有那么崇高，而且 ...继续阅读 (62)

光是放在blog上面的文字，已经超过三百篇。我觉得哪怕是在工地拉砖头，也应该是时候直起腰回头瞅瞅了。所以就有了此文，但是和十多年前的我不同的是，我应该不会发很多牢骚，而另一方面，我也不像是个理性到每逢这种时候都要摆一大迭数据出来说事儿的人。所以，大概还是扯扯东、扯扯西，这篇纪念就过去了。这当中该用力地记到脑子里的，会慢慢沉淀下来。宏观地且从粗暴的统计来看，大概两年前的我，那个时候是最能写的。那段时间无论往前数还是往后数，生活或工作的繁忙程度都要增加许多，这无疑影响了我做这些笔头事情的效率。最近可能是年纪增长的关系，我不断在思考一件事情，到底做点什么才是最值得的。我不是什么特别有规划的人，除去工作和每天一些固定的时间开销，我突然发现我反而不会安排生活了。这种感觉很奇怪，我记得读大学的时候很多人就不断说自己不知道该干什么，不知道未来在哪里，我倒是每天把事情安排得很满，虽然也不见得总是什么多光彩和有价值的事情。工作七年多以后，反而有了种茫然的感觉。也许我是需要一点变化了。一位同事告诉我，其实这种牢骚他们早就有了。特别是那种博士毕业学成离开的心态，无论多么心比天高的傲气，都慢慢挫败在日常的琐事和就业的磕磕碰碰中。这一路的大多数人都曾经在读书时期是无比风光的，要不也没法读到博士。其中有位学冷门专业的同事，拿了各种奖学金，毕业以后也迫于生活压力转而投身软件工程，数月后，“忽然就成了码农”。茫茫 ...继续阅读 (79)

以前有一个电子琴，只是时不时的折腾一番，也没有养成良好的读谱习惯，进步很慢。其实很多人都和我一样，心中从小就有一个各种各样的和艺术沾点边的梦，身边有画画很棒的，有下棋很牛的，还有同事每个月都会去跳舞，我和我老婆说，从小就喜欢折腾各种音乐器械，要不我也正儿八经学学钢琴，开发开发智力？她说，要不先弄你的电子琴吧，要是能坚持下来，再投资钢琴。差不多快一年，事实证明这个兴趣应该是可以坚持下去的。于是请了老师，每周一课。又过了一段时间，老师说，你得去弄一台真正的钢琴了，电子琴不是长久之计。我做了做功课，有位同事家也有钢琴，不过是电钢琴，看到其中的好处之后我有点心动（比如可以调音量，便携，还可以编曲）。结果自己跑了琴行以后，一下就把电钢琴的选项排除掉了，因为触感实在是没有办法和真正的钢琴相比。我们折腾了两个周末，先选类型，自己先听、先比较，再请专业的调音师帮忙听，搞定了一台价格不菲的Yamaha钢琴。这几个月练下来，还是觉得又有设备、又有老师，确实比单纯自己琢磨进步快多了。成年人和被逼练琴的小孩不同，理解力强得多，乐理知识什么的一下就接受了。但是相较于孩子来说，明显缺少时间，每天下班以后，有时觉得已经累成狗了，还要挤出时间来练琴。因此坚持一个爱好，总是不容易的。而且，成年人不再像一个孩子那样是一张白纸，构建记忆，特别是肌肉记忆的时候，没有像孩子那样快。但是，话说回来，成年人心里清楚得很，想要什 ...继续阅读 (59)

最近的工作总是在EMR上跑Spark的job，从代码完毕到测试完毕的过程是这样的：1. 本地测试：    构建 -> 本地UT -> 观察分析结果，这一阶段可以发现逻辑问题2. EMR上执行测试：    上传最新构建到S3 -> 准备EMR资源（包括计算资源和数据） -> 在EMR上执行Spark job -> 观察分析结果，这一阶段可以发现在数据量较大的情况下才出现的问题3. Workflow集成测试（这个workflow是公司内部的一个管理job的工作流系统）：    启动workflow -> 观察job状态 -> 等待workflow调度和资源分配 -> 等待workflow执行结束 -> 观察分析结果，这一阶段可以发现在workflow配置、参数等环境上的问题现在回过头来看整个过程，基本上思路还是清晰的，但是，一开始不是。开始的时候我没有做第二步，直接从UT跨越到workflow上的测试，结果就是效率低下，大量的时间都在等待workflow的调度和资源分配，跑一次任务得等上一个半钟头以上才能看到结果。所以，经验教训就是，测试要有层次，简单的东西写了跑很方便，但是异步job这样的东西，特别是数据量大的时候，根据不同的测试成本分成不同的阶段，尽可能在测试成本最小的 ...继续阅读 (63)

最近开始学习Scala，相较于学习Haskell的过程来看，Scala真是直观得多，友好得多，更容易上手。以前写过关于从熟悉的Java和JavaScript来逐步学习Groovy和Haskell的文章，这以后再来学习Scala的话，就可以不断比较了。如果和我一样有Java经验的话但是从来没有接触过Scala的话，建议先阅读这篇文章，A Scala Tutorial for Java Programmers，一边比较，一边熟悉，同时配套的还有这个，Scala for Java programmers – Joakim Ohlrogge & Enno Runne，Youtube上的视频，很直观，然后再从Scala官网的文档上面逐步涉入。这里的模式匹配可能是历经函数式编程才引入的概念，是广泛存在于编程语言函数使用中的，而并非以前接触的“正则表达式”这样仅仅用于字符串处理的特性。在此之前，先来看看Haskell中的模式匹配，我在这里曾经举过这个阶乘的例子：factorial :: (Integral a) => a -> a factorial 0 = 1 factorial n = n * factorial (n - 1)根本不需要多余的解释，一眼就看懂。模式匹配在这里起到了if-else的作用，对于逻辑的执行，起到了一个“变化点”的作用。在以往传统的静态语言 ...继续阅读 (64)

写在双红会之后。曼联遇到利物浦，最近这一年多来，总是可以拿到酣畅淋漓的胜利。从莫耶斯到范加尔，其中的转变，这是一个缩影。毫无疑问范加尔是个颇具争议的主教练，他的身边从来不缺新闻话题，而且他的孤傲和弗格森还不一样，他喜欢把各种内部消息往外抖，说他心直口快也好，说他脑子缺根筋也好，反正记者爱听他爆料，球迷也爱听啊。就在没多久前，因为花了几千万签下一个名不见经传的马夏尔，还受到各方质疑，连他自己都承认，这个价格有点疯狂。战术层面说范加尔战术死板那绝对是有道理的。事实上，球员被允许自由发挥的余地并不大。关于球员自由发挥，这个和教练有着密切的关系。范加尔是个典型的control freak，从训练场到集体活动，细节全部把控。去年一年战术在不断调整，最早尝试过一段时间352，三个中后卫排开，两个边翼，但是效果不佳，英格兰环境下渲染的球员不太会打这种阵型，速度慢，球还倒不开。现在的四后卫体系已经熟悉，中场有时候放双后腰，两个边锋顶上去，中路看情况是摆一个二前锋（进攻），或者是一个前腰（控制）；有时候则是摆典型的4141，中场一字排开。无论哪一种，前场的压迫性做得比上个赛季好很多。关于范加尔的控制欲，在战术体系的细节上可以看得很清楚：左右中卫必须是一个左脚一个右脚，这也是他买罗霍的一个原因，是把布林德放到左中卫上的一个原因；左右两个边锋，必须内切，左边的孟菲斯德佩也好，阿什利杨也好，右边的马塔也好 ...继续阅读 (68)

从毕业工作到现在，已经有七个年头，年头虽然不久，但是回过头来看看那些经历的好的坏的有趣的扯淡的事情，还是有很多东西可以总结。所有人都会或多或少走弯路，本来成长就是这样一个过程，有时候想起来会感叹，有时候会唏嘘，有时候会一笑而过。我的前一半时间是在华为，这段时间留给我很多回忆（比如这几个瞬间）；后半时间在亚马逊，也给了我不少感慨的机会。下面这些故事都是我经历的真真实实的事，有的事情已经过去好久，但我不想把它永远尘封。也许你和我在某些方面，会有共同的体会。在我说这些故事前，或者说，吐这些槽前，我想说这样三个观点。首先，为自己工作。不是为父母，不是为同事，不是为公司，不是为项目，不是为绩效。几年以后你离开，项目的成就属于公司，绩效已是过往云烟，你获得了收入，公司得到了效益。一身行囊离开的时候，除了一些积蓄，就是你的经历，你的态度，你的身体，还有，你的技术。没有人会为你的决定买单，父母不能，亲友不能，只有你自己；没有人再会在乎你前一家公司考评得到的是A还是B，你为公司项目付出了多少、赢得了多少。感情上有无数种结果，但是事实上只有一种。这个道理很简单，但是为了明白它我花了很久的时间。每一家公司都有它的企业文化，人在努力建立自己正确的职业观的时候，总是会或多或少被这样那样的企业文化所影响，严重的可以说，所洗脑。我有点庆幸似乎这个影响并不非常深刻，无所谓对错之分，但是人唯一可以减轻某一种激进的和 ...继续阅读 (89)

看完两场英超，引援上估计除了待定的佩德罗以外，不会有什么大的变数了。想起去年赛季伊始，在知乎上面回答了几个和曼联有关的问题，现在正好回过头来扒坟，比如关于曼联的拉斐尔，说“他也就是一员猛将，刚猛有余，智慧不足，前途平庸”，目前看来是正确的，已经离开前往法甲；说费莱尼“在当前全攻全守和控球理念强调下范加尔治下，费莱尼很难在球队中有他的一席之地”，很遗憾这条错得离谱，但是话说回来，费莱尼尽管上个赛季令人惊讶，但是我依然认为他和范加尔脑海中的建队思路有所违背，位置不稳的。范加尔上任以后屡遭非议，即便在去年范加尔成绩最差的时候，差到都不如同期莫耶斯，我依然很有信心地觉得看球不能观看比分和成绩，从改造和和场面来看，值得对他抱有重返欧冠的信心，他和莫耶斯不是一个级别的人物：今年也一样，挨个位置谈谈范加尔对球队的改造。范加尔对球队的改造是有目共睹的，和前任莫耶斯比起来。我始终坚定地认为，弗格森退役以后留下的阵容班底，从常规的角度来看，实在是太弱了，也就是一个英超前六名的班底，莫耶斯的成绩不好，战术素养、球队建设都差，但是手上的牌确实也有限。有人总在说那是冠军班底，可冠军又如何，我不相信当时那批人，交给其他任何一个英超教练，可以像弗格森一样拿到冠军。弗格森在卖掉C罗以后，对球队建设的投入力度是不足的，这会耽误好几年，它的影响在如今也能看出来。不要总提92一代，如今的英超青训，确实是远不如前了。当然 ...继续阅读 (57)

作为系统设计学习的一部分，不久前在梳理面试中典型的系统设计问题，发现大部分都可谓有套路可寻。我把思路梳理了一下，简单整理到下面这张图表里面：对于其中的内容，稍微补充几句：系统设计需要经验的积累，但也确确实实有章可循。问的问题考察的类型很集中，比如同步、异步，消息push和pull，根据实际问题设计存储的数据结构，对于scalability、availability的认识等等。最喜欢被问到的问题，我在《系统设计典型问题的思考》这里列了几个。pull on demand 和 push on change 是消息系统里两种极其典型的消息传播方式，基本上设计twitter、weibo，xx聊天系统等等，都要涉及到这个问题。这二者各有优劣，需要结合具体问题分析。复杂的系统的cache的设计和storage的设计一样，往往需要考虑分层。比如说，存储分成hot/warm/cold storage，读写性能和查询的灵活性依次降低，但是成本也依次降低。cache的设计有时还需要引入centralized cache来帮助提高hit ratio。服务端的设计最典型的就是分成三层（上图右）：presentation layer，比如website的页面部分和service的request/response处理的部分；business logic layer，放置业务逻辑的地方；data access l ...继续阅读 (54)

只是记录一下遇到的几道抛硬币的概率问题。1、平均需要抛掷多少次硬币，才会首次出现连续的两个正面？假设连续两个正面的期望是E，那么，先看第一次抛硬币：如果抛到反面，那么还期望抛E次，因为抛到反面完全没用，总数就期望抛E+1如果抛到正面，那么要看下一次，如果下一次也是正面，那抛硬币就结束了，总数是2；如果下一次是反面，那么相当于重头来过，总数就期望抛E+2于是可以得到如下关系式：E = 0.5(E+1) + 0.25*2 + 0.25(E+2)得到所求期望E=6现在把题目拓展，不是说“连续两个正面”，而是“连续n个正面”呢？这个问题Matrix67有非常有趣的解答《用数学解赌博问题不稀奇，用赌博解数学问题才牛B》，下面我简述一下：假设有一个赌场，赌博的方式就是猜正反，每来一个玩家来的时候都只带了1元，每次都会全部下注，然后赌正面，庄家抛硬币，如果猜错就是全部输掉，如果赢了就得到下注的两倍，玩家会一直玩一直玩直到钱输光；而赌场老板会看，如果有人赢到2^n元，就下令关闭赌场。于是直到n次正面朝上的情况发生，赌场关闭，只有最后那n个人才赚到了钱，最后一人得到了2元（没算成本价1元），倒数第二人是4元……倒数第n人是2^n元，所以，一共得到（等比数列求和）：2+4+8+…+2^n = 2*(1-2^n)/(1-2) = 2^(n+1) – 2赌场有多少钱流入，自然就有多少钱流出，所 ...继续阅读 (60)

这是这个系列的最后一篇，从编程范型的角度概览，前面几篇的链接在文章后半部分有汇总。我在之前已经介绍过编程范型的概念，而事实上，我们到现在为止，纠结在这四门迥异的语言上面，浅看是各种语言特性，深看就是编程范型和思维方法。下面这张“神图”来自于这里，可以说是对于范型和语言归类的概览，从左往右从更强的声明式向着更弱的声明式发展；依据状态分为Unnamed state（串行或并发，包含逻辑式和函数式这几种分类）、Nondet. state（所谓的不确定性状态）和Named state（包含数据流、消息传递和状态共享这几种分类），Haskell出现在了左侧函数式语言的分支内，而Java出现在了右侧状态共享的分支内。有了这棵大树，范型之间的关系变得很容易识别，比如这样的粗线条：最初的范型仅仅是简单的“record”而已，纯粹的声明和静态的描述；有一天加上了过程，于是有了一阶函数式编程；之后有一天再加上了状态，于是有了命令式编程。一阶函数式编程加上闭包，得到了真正的函数式编程（有了闭包，就可以写高阶函数了）；命令式编程加上对函数的搜索，就得到了串行的OO以及状态共享的函数式编程。……从维基百科的Comparison of multi-paradigm programming languages词条中，可以看得到常见多范型语言的分类情况。Java和JavaScript位列其中，从表中的分别可以看出 ...继续阅读 (72)

昨天刚从Lake 22远足回来，感觉很疲劳，回想起这些时间的远足经历，可以写一写其中的感受。如果你也有此长期计划，打算用远足的方式来充实生活，或者锻炼身体，甚至只是打发时间，那可以参考下面的文字。首先，我不是驴友，我也没有专业的远足设备。我只是在周末天气不错的时候，用远足的方式给自己找点乐子。经过一段时间的熏陶以后，就像写博客一样，已经养成了习惯。我在《旅行映像》里贴了一些远足的图文记录，但是远足带来的体验，远不止所谓的“看风景”。本人甚业余，专业党、野餐党请绕路。准备工作很简单，但是却少不得。平均起来，一个月四周的话，基本上有三周我都会去选择远足，时间一般都在周末。如果要去远处，或者步行距离不短，周六更好，这样周日可以有一天休息，不会影响到周一的工作。准备一次近距离的远足通常很简单，打开Google地图，寻找周边两个钟头车程内地点，基本上完全凭喜好挑选。准备一双轻便透气且不容易打滑的鞋子，根据天气的情况带水，还有少量食物以备急用。我一般都带一瓶矿泉水，还有几片饼干，包里放一块巧克力。水和食物很重要。看起来准备环节很简单对不对，一般挑选下一个地点，10分钟内就搞定了。但是需要注意的是，要先预先考虑好停车场，根据停车场的坐标去导航。在Google地图上，选择一个景点以后，可以看得到许多人简短的review。一开始可以选择review比较多的地方去，那些地方有名、人多，景色也不差，基本 ...继续阅读 (58)

这是《从Java和JavaScript来学习Haskell和Groovy》系列的第四篇。首先来理解DSL。DSL（Domain Specific Language）指的是一定应用领域内的计算机语言，它可以不强大，它可以只能在一定的领域内生效（和GPL相比，GPL是General Purpose Language），表达仅限于该领域，但是它对于特定领域简洁、清晰，包含针对特定领域的优化。当我们面对各种各样的特定需求的时候，一个通用的语言往往不能高效地提供解决问题的路径，相应的DSL并不是并非要解决所有的问题，但是它只关注于某一个小领域，以便解决那一个小领域的问题就好了。比如HTML，只用于网页渲染，出了这个圈子它什么都不做，但是用来表达网页的内容却很擅长，有很多内置的标签来表达有预定义含义的内容；再比如SQL，只能写数据库相关的操作语句，但是很适合用来描述要查询什么样的一个数据集合，要对数据集合中的元素做什么样的操作。 先来看Java。用Java写DSL是可能的，但是写高效和简洁的DSL是困难的。原因在于它的语法限制，必须严谨的括号组合，不支持脚本方式执行代码等等。首先讲讲链式调用。这也不是Java特有的东西，只不过Java的限制太多，能帮助DSL的特性很少，第一个能想到的就是它而已。比如这样的代码，组织起html文本来显得有层次、有条理：document .html() ...继续阅读 (72)

我们这一代人，很多都有一个不断演化着的音乐的梦想。我们欣赏过很多音乐，听过很多歌，打开豆瓣音乐的时候，当我选择“八零后”频道，我确确实实感受到这些歌曲就是属于我的世界的，很难解释其中的原因。虽然现在有时候依然去听那些新歌，但是就是很难再找到那根打动自己的神经。我听张信哲的歌，最早最喜欢的是《别怕我伤心》，甚至在一些公众场合我都愿意拿出来唱一唱。还有《爱如潮水》，当时买的是磁带，哪有什么CD啊。后来看了《宝莲灯》，一遍遍听《爱就一个字》。我听梁静茹的歌，从最早的《一夜长大》开始。我喜欢她那些有故事的歌曲。她有很多歌不只是曲子好听，歌词也越听越有味道。有一首歌，《绿花》，词曲我都非常喜欢，据说原来名为《绣花》，很少人听过，因为它并未被正式收录：听着风吹开落叶一丛低着头思念轻轻经过尘埃堆积了多年的梦锁在古老的笙乐中推开了心中的门寻不到你的影踪相比起现在那些无比直白而琐碎的爱来爱去恨来恨去的词曲，我更怀念这种遗失的婉约。《我还记得》则不需要任何过多的煽情，“沉默里千言万语”：十年后的今天遇见你年少轻狂已远去成熟稳重也保持距离沉默里千言万语我听无印良品的歌，每一张专辑都历历在目，可惜他们已经单飞多年。我不知道为什么如此喜欢他们的歌，我觉得每一首都如此上口，声音干净，独树一帜。《伤心地铁》，“我独自在陌生的世界，在这伤心的地铁”。《朋友》（非周华健那首），如此上口，简单而亲切。即便现在，我还经 ...继续阅读 (67)

本篇文章的话题是元编程。首先来认识元编程，我在第一篇《引子》里面已经介绍：元编程，指的是在运行时改变“类”的定义，例如访问、增加或修改等等。一言以蔽之，就是“用程序来写程序”。在第二篇的《类型系统》里面已经借由继承和接口的实现，介绍了一些利用元编程特性来增加或改变子类行为的方法。回顾语言发展的长河，其实是经历了一个从“对象 -> 类 -> 元类”到“对象 -> 原型”的发展过程的。所以，无论是类，还是元类，这样的概念其实都不是非有不可的，只是因为我们思考的习惯，特别是抽象的习惯而顺其自然地产生了。这一点我在《编程范型：工具的选择》里面已经详细描述了，建议在往下阅读前移步。正式介入元编程的部分，先来看看Java，它的方式比较原始，也比较清晰，本身它定义了Class、Method、Field等等描述一个类的基本概念，基于静态语言的限制，没有办法真正在运行时改变一个类内部的结构（但是可以在运行时获取一个类内部的结构），于是有了像CGLib这样在运行时使用动态代理，创建一个类来替代的办法，让使用者看起来好像是改变了原始类的结构。当然，在编译期，像AspectJ这样的工具可以做到真正的“织入”逻辑，控制字节码的生成。对于Java的元编程本身而言，即便到今天，局限性很大，但是局限性并不意味着有用性，可以说如今元编程的应用已经铺天盖地，其中有这样两件事情大大加速了它元编程的发展：一是JDK 5的 ...继续阅读 (78)

LeetCode上面的题目更新很快，而且题目是越来越不好做了。我把最新的155到226题目的思考和解答过程放在下面，解法有好有坏，有问题我们可以讨论。老规矩，有一些题目是要买一个特定的电子书才可以在线做题的，我就跳过去了。#TitleAcceptanceDifficulty226Invert Binary Tree37.6%Easy225Implement Stack using Queues30.0%Medium224Basic Calculator16.1%Medium223Rectangle Area26.0%Easy222Count Complete Tree Nodes19.8%Medium221Maximal Square20.6%Medium220Contains Duplicate III15.0%Medium219Contains Duplicate II26.2%Easy218The Skyline Problem17.0%Hard217Contains Duplicate35.9%Easy216Combination Sum III27.3%Medium215Kth Largest Element in an Array27.4%Medium214Shortest Palindrome16.3%Hard213House Robber II26.1%Medium ...继续阅读 (86)

最近在忙于公司内部换组的事情，在亚马逊等等很多公司都有这样的政策文化，就是，如果你在这一个组工作一年以后，并且绩效不太差的话，都可以自己去寻找觉得喜欢的团队加入。我在当前的这个大组干了两年多了，经历了一些成败和风波，我觉得是时候离开去寻找一个更合我胃口的团队了，增加阅历和体验，当然，也肯定是新的挑战。在思考自己的职业未来的时候，其实是有不少选项的。大约是最近这一年，我越来越感觉到，在Amazon工作，那么多内容里面，最有价值的大概是数据，我寻找的下一站，也是想多参与和大数据更紧密的工作。如果说以前我的工作更像是一个full stack engineer的话，接下去一段时间，我要更多地和数据、计算，以及各色job打交道了。希望自己这部分能够得到增强。我想起我第一次换工作，实在11年底12年初，正好距离我毕业踏入职场三年半时间，而这以后到现在虽说不换公司，但是也算是比较大的变动，也是三年多的时间。职业生涯有多少个三年？说到我想要离开现有团队的原因，主要是两个方面，一个是做的东西范畴还是偏小，在一个大风格的大team内部，缺少足够的关注，不容易赢得同行工程师足够的认可。再一个则是确实已经在这个组织中呆了接近三年的时间，也到了一个对新事物渴求的时期，希望自己更多的方面得到成长。另外，H签证没有抽到，因为L签证的关系，跳槽成为了不可能，要不然我也很愿意在适当的时候去尝试那些更不同的新体验。一 ...继续阅读 (60)

最近看到这篇文章《小伙伴们手滑集》，觉得感慨很多，强烈推荐大家阅读。比如这样的例子：UPDATE没有WHERE条件而我则经历过delete没有写where条件的惨剧，这个惨剧是某些case下面代码调用触发的，不是手动执行SQL发生的。还有臭名昭著的，我没有经历过，但是我有不止一个同事干过这样的事情：rm -rf都只是手稍稍地温柔地“滑了一下”而已嘛……这些事情我觉得一下子很亲切，似乎全世界的软件工程师都是如此得同一。出的事故多了以后，变得战战兢兢，如履薄冰，尤其是回车键这样的敲击，似乎总是带着颤抖落指。还有这篇文章《让自家系统瘫痪，这事我也干过》，讲了一个关于使用truncate语句清空数据库数据的故事。及时报告老大，但是领导给了这样一个反馈：赶紧恢复数据，最迟明天早上必须要解决，不要让用户感觉到。其实这样的话是非常给程序员压力的，我可以想象当时那种场景。线上数据丢失是如何惊心动魄。作者给了这位老大一个很高的评价，但是我不这么认为。这件事情最终大事化小、小事化了的做法是很不错的，但是给出时间点压力这样的事情其实对当时火烧眉毛的情况解决并没有帮助。谁都会有手滑的时候，我最大的感受是，在“线上系统维护”这样的事情上，“人”远没有“机器”可靠。造成的恶劣后果多半为“服务停止”或者“数据丢失”两种，尤其是后者，有时难以挽回，损失惨重。我经历过的“手滑”惨剧也有一些，当然没有那么恐怖。比如在 ...继续阅读 (57)

大学里面算法课老师教导过动态规划，但是就像看书要把书看厚再看薄一样，要把动态规划彻底理解，还是需要一些时间的锻炼。解动态规划问题，每个人都有自己的习惯的套路，我的理解是最核心的过程有两部，一个是找出问题的一个一个子“状态”，再一个就是建立“状态转移方程”（就是所谓的“递推关系式”）。把这个过程搞定，基本上动态规划的题目就解了一半了，剩下那些代码层面的事情，是把思路和数学方程实现而已了。在实现的过程中，可能会用到一些技巧，比如“循环还是递归”，这只是实现的办法而已，不是动态规划的本质；再比如空间换时间，把子问题的解答结果（就是上面说的子“状态”）存放起来，减少重复计算，这也是优化的办法，也并非动态规划本质。因为最近正在复习这方面的算法，下面的笔记是以LeetCode上面打着动态规划标签的题目中的一些典型问题为例（我以前做过这些题目的解答汇总），来说明“状态识别”和“状态转移方程建立”这两个步骤的思考过程。这类问题遇到得多了以后，思考就会快一点：Word Break【题目】Given a stringsand a dictionary of wordsdict, determine ifscan be segmented ...继续阅读 (59)

最近耳道感染，左耳朵又堵又疼，在美国几次就医，本人虽非医学专业出身，但从局外人的角度，想到和国内那些求医的历史，还是有一些比较可言。首先对于医生的划分，国内基本上就是根据科室来完成，一个医生在一个科室，时间久了，经验丰富，遂成为出名的医生。好处在于医生更能够专精于自己的一亩三分地，专科阅历容易积累。而看看许多国内的专家，有大量的机会见各种各样奇怪的病人，并且手术的机会也会非常多，因此我猜测经验会更加丰富。但不足之处在于，对于病人来说，疾病往往是复杂性全身性的，可能对要挂哪个科室并不清楚，即便到求医中后期，都有可能面临多科室一同合作的情况，这些情形都容易导致耽搁病情。而美国的医疗体系，医生分为家庭医生和专科医生，家庭医生数量巨大，这些医生又称作全科医生，什么都管，绝大多数问题，到了他们那里，都可以解决掉。真正解决不掉的，再由他们推荐给相应的专科医生处理。优点在于资源可以高效利用，专科医生接管的病人，都不是那种显而易见或者很容易打发的疾病；再一个对于病人而言，很多病人都有自己长期合作的家庭医生，可以说有助于培养熟悉和亲切的医患关系。其次说说就诊过程。国内基本上都是挂号体系，大部分号都在现场挂，排队等，少部分号通过电话或者网上预约完成。由于人口过多，而且三甲医院和地方小医院医疗水平差异过大，导致大型医院的医疗资源过度集中，挂号非常困难。而且由于众所周知的长期以来的医患问题，都愿意去找&l ...继续阅读 (61)

6天7夜，仅游玩了O’ahu一个岛，后来总结如果高效率地行进，可能这个岛屿4天就可以玩的差不多了。我很喜欢旅行，但是在旅行计划方面不太在行。夏威夷和我以前去过的菲律宾长滩岛比起来，更加现代一点，价格也贵了接近一倍。期间我们没有坐公交车，全程都租了车行进，并且我觉得花掉的钱里面，租车是最值得的。我把这篇文字记录下来，如果你也有夏威夷的出行计划，那么可以参考参考。家人和我一起来，都说三个女人一台戏，至于四个女人嘛……反正一路上叽叽喳喳的。第一天：东线海滩是夏威夷的重头戏，如果说论美丽的海滩数量，夏威夷可真是不少。当然，去多了可能觉得大同小异。我们经常开开车看到美丽的海滩就停下来，海水或清蓝或透绿，所以要提前穿好泳装。在Kailua海滩可以喂鸽子（自己带点面包或饼干就好），也可以尝试一把Kayak。在海边消遣的人中，有下海游泳派的，有沙滩晒太阳派的，本人属于海边松树林中睡觉派的。Hiking方面，我们去了Diamond Head，到达山顶的时候景色非常漂亮，一半山和城市，一半海和小岛，这比单纯的海景要好看。一定要涂抹防晒霜，100倍的那种。怕晒黑的同学，就别旅行了，防晒霜不是用来拒绝晒黑的，而是用来拒绝晒伤的。平时不爱在外面疯的外地人，没有防晒霜的话大概两三天就晒脱皮了。当地人很多都别一个鸡蛋花：第二天：北线一早去了植物园。西雅图附近爬了无数的山都难以见到的热带植被。巨大的榕 ...继续阅读 (65)

读模型1、主键读最常见的读模型，说是主键，其实也包括其它索引键，或者联合主键。常见实现：hash，时间复杂度可以接近O(1)；B树或变种：时间复杂度接近O(log(n))。关于B树和变种：B树（B-树）：本质上是二叉查找树的升级版，变成了平衡的N叉查找树，这个N的范围根据磁盘一次读取的块大小来调整，这样复杂度log n的底数就从2变成一个更大的数，减少了树的高度。除此以外，还有一些额外的优化，比如为了插入和删除的性能考虑，通常准备一些预留的空间，只要在当前块或者邻近块中找到空间写入，就避免了开销巨大的所有记录向后偏移的操作。B树的阶：一棵m阶的B树最多有m棵子树；根节点至少有两棵子树；每个非根分支节点至少有ceil(m/2)棵子树；叶节点全部在同一层；有x个孩子的非叶节点恰有x-1个递增排列的关键字。图片来自此页面。B+树：和B树相比，改变的地方包括：全部关键字信息都放在叶子节点；所有叶子节点串成一个linked list以便搜索；存放重复的搜索键。具体的区别可以参见《Difference between B Tree and B+ Tree》，（下图出处）。B*树在B+树基础上做了进一步改进：非叶子节点增加指向兄弟节点的指针（用以在节点满时，可以往兄弟节点放数据，减少节点创建的情况）；非叶子节点至少为2/3满的（关键字字数至少为最大值的2/3）。2、指定页查询指定页就意味着具备分 ...继续阅读 (54)

接上文《从Java和JavaScript来学习Haskell和Groovy（引子）》。首先搞清几个概念：动态类型（Dynamic Typing）和静态类型：区别的核心在编译期还是运行时。静态类型的语言系统在编译期就明确知道每一个变量的类型，如果发现不合法的类型赋值就在编译期报错；动态类型则直到运行时才会报错。类型推导（Type Inference），类型推断是指可以在上下文中，编译器来推导实际的类型，也就是代码使用隐式类型指定。比如一个简简单单的“var a=1”，a就被推断成整型。弱类型（Weakly Typed）和强类型：指的是语言系统对类型检查，或者是类型之间互相转换严格的程度。比如C和C++就是弱类型的，类型不安全，或者说类型转换其实是开放的，这个自由度带来的风险由程序员自己承担。另外还有两个概念，Structural Typing（结构类型）和Duck Typing（鸭子类型），这两个都是面向对象里面的概念。如果两个类暴露的所有方法的签名都相同，那么可以说他们具备相同的结构类型（在《多重继承的演变》里面介绍过它）。鸭子类型的要求则宽松得多，如果两个类或者对象暴露的某个或者某几个方法具备一致的方法签名，比如这个方法表示鸭子的嘎嘎叫，那它们就都是能够嘎嘎叫的鸭子，而并不需要实现什么接口或者继承什么类。鸭子类型的使用多数出现在动态语言中。把我们今天涉及到的语言放进去，来举几个具 ...继续阅读 (68)

我记得刚接触计算机的时候，我就受到了两个非常巨大的错误观念的影响，这个观念最初是来自于老师的传授还是学长的教诲已经记不清了，但是直到我工作几年以后，才慢慢有了实际的体会：学习和使用什么编程语言不重要，重要的是算法和设计；程序员学习的精髓是面向对象的设计模式，掌握以后，一通百通。简直就是是胡扯啊。也许在某个极其狭隘的上下文中还能这样说，但是泛泛而谈，这样的态度无疑是误人子弟的。就说第一条，编程语言不但重要，而且太重要了。换句话说，学习一门新的编程语言，可能学习的是背后的范型和思考问题的方式。如果这个部分能带来新的东西，那就是值得花时间投入的。可能很多人和我的背景一样，熟悉Java和JavaScript，一门是经典的静态语言，一门是经典的动态语言。有人说相较而言，搞C++背景的人算法和数据结构基础更加扎实；而起初搞Java背景的人可能设计方面懂的多一点，但是水货更多；而说起JavaScript，就似乎更“低廉”了，虽说学好太难，但入门门槛超低。于是针对像我这样背景的工程师，我打算用类比Java和JavaScript的方式写一些新的编程语言的学习笔记，因为在我看来，用“类比”的方式是学习印象深刻，而且容易更容易理解的有效方式。以前也用类似的方式写过一些新技术的学习笔记，比如《GWT初体验》。但是通常要学习一门新的编程语言，尤其是从未熟悉的一个新的编程范型，学习曲线要比这个高得多。在我的脑 ...继续阅读 (56)

前方鸡汤高能预警。读书的时候，曾经听到这样的说法，最近几个月，则又听到了两三次，人生选择论，鱼和熊掌说，或者生活跷跷板理论。跷跷板的特点就是，一头摁下去，另一头就起来。本人向来鄙视鸡汤，不过这个理论还是比较赞同的，看来今天破一次例。选择了A，就失去了B；选择了B，就无法得到A。所谓鱼和熊掌无法兼得便是如此。生活总会值得吐槽毕业后在南京工作的时候，觉得气候还算过得去，吴侬软语听起来也顺耳，但是地方实在是太小了，很不甘心在这个小地方一直耗下去；到了北京，确实见了世面，确实是我所说的“更大的盒子”，但是又觉得环境太过糟糕，交通无法忍受；现在来到西雅图，平日里吐槽惯了，环境是好了，见识是增长了，又觉得不够热闹，生活不够丰富，怀念起北京那种下楼二十米内一排小吃店、菜场和小卖部的壮观景象。工作也不安分以前也写过一篇文章随便谈谈“不安分的工程师”，到现在我也不知道这个不安分的天性是个人先天性格因素还是做的事情在后天培养的。反复地做一件事，例如把一个Excel的表格中A列拷贝到B列，每天都做，做二十天。有人会老老实实做，可能每天花不了几十秒，二十天下来，也未必花多少时间；有人（譬如很多工程师）会想写脚本，这当中可能并不顺利，花很多时间调查技术、调试错误，最后总花费的时间远远超过了那二十天老老实实干活的总时间。但是我觉得许多工程师还会本能地、奋不顾身地 ...继续阅读 (52)