记录 Seaborn 的工作，学习和生活，欢迎关注
昨天说完了确定时间，场地和题目。今天来说说活动当天要做些什么。
记录 Seaborn 的工作，学习和生活，欢迎关注
记录 Seaborn 的工作，学习和生活，欢迎关注
今天第一次讨论非常成功，大家的积极性都很高。 讨论出的结论如下：
今天学习小组进行了第二次分享，有一些小小的不顺利，主要有： 一、演讲人以为是明天讲，也怪我前期沟通工作一到位； 二、会议室找了好几个都有人在，没想到大家工作这么努力，中午都在开会呢； 三、关于之前定的一天一次分享，有的同事认为太过频繁，经过讨论改成每周一、三、五分享。其实我是希望大家都能先讲上一两次，找找感觉，然后再听别人讲的时候也能和自己联系起来，这样收获会更大。我也思考了一下，不能让大家觉得很有压力，如果活动成了任务和负担，那样不会有任何效果，还是慢慢来吧。
Date: 2013-07-31 11:30:18
最近读到两篇文章挺有感触的，意思都差不多，主要观点是：
![办公室里的圣诞树] (/_image/2013-12-25/IMG_20131224_171330.jpg)
我上周六参加了一个「幽默即兴表演」的工作坊，周日看了一场脱口秀演出，体会到了幽默和逗逼的区别。
记录 Seaborn 的工作，学习和生活，欢迎关注
不断的 IM 消息和邮件，把时间切的稀碎，而写代码需要一段比较长的时间才能进入状态，所以我们往往在白天根本写不了什么代码，只能在晚上测试，业务，客户都下班后，默默地写代码。 然而，一天的碎片化信息和多任务切换后，我们的精力已经消耗殆尽，晚上写代码的质量不高，写Bug效率很高，所以虫子（Bug）都喜欢晚上出来，等白天来临，业务，测试回到工作岗位后，就会发现我们置入的这些Bug，从而又给我们发消息，准备数据，配合重现和确认，修改代码，再次验证。如果流入生产，就会被客户发现，从而上升到最高等级，必须停下手里的工作去救火。 这样，我们的时间就更碎片化了。聪明如你肯定看出来了，这就是一个恶性循环呀。 你说那我不会消息可以吗？不行，因为如果没有及时回复别人，在绩效沟通时可能就会得到一个「不善于团队合作」的评价。
幼师，一个神圣的职业
记录 Seaborn 的工作，学习和生活，欢迎关注
特别强调自我发现，我们远离工作压力，放慢节奏，去观察自己的编程习惯。 每一轮的搭档切换有助于 Coderetreat is a dynamic day with the specifics molded to the individual participants. There is a strong emphasis on self-discovery. The intense pair-swapping allows ideas to rapidly disseminate through the group. The frequent session reflections help with more complete internalization of lessons. Starting over allows experimentation without the baggage of previous experiments. To ensure the objectives of the coderetreat are met and that the participants get the maximum value out of the event, it is essential to have a facilitator for the day of coderetreat. The facilitator's role is to guide the participants through the various paths of experimentation, putting appropriate pressure at each stage of the day.
记录 Seaborn 的工作，学习和生活，欢迎关注
记录 Seaborn 的工作，学习和生活，欢迎关注
记录 Seaborn 的工作，学习和生活，欢迎关注
引言
记录 Seaborn 的工作，学习和生活，欢迎关注
记录 Seaborn 的工作，学习和生活，欢迎关注
记录 Seaborn 的工作，学习和生活，欢迎关注
记录 Seaborn 的工作，学习和生活，欢迎关注
我是一个拖延症晚期患者，因为确实病得太重，一直拖着也没去治。 最近有人说我高产，我仔细一想，确实每天写一篇文章也不是一件容易的事。 我就开始思考，我是怎么从一个拖延症变成高产博主的呢？
前几天分享的时间管理文章里提到了晨间日记，有小伙伴留言说想尝试，不知道具体怎么写。 今天就分享一下，我写日记的经历，以及晨间日记格式的演变过程。
记录 Seaborn 的工作，学习和生活，欢迎关注
技术教练团队对于企业的意义 痛点 数字化转型迫切 数字化转型中，持续交付的能力是核心能力。要实现持续交付，需要 CI/CD 流水线，微服务架构，容器化等新的技能。其次必须把质量工作前移，从检测变成预防，让开发人员对质量负责。传统的开发负责功能开发，测试人员负责质量保障的模式，几个弊端： 发现问题相对较晚，修复成本更高，还有开发人员与测试人员之间的沟通成本和开发人员在开发新功能和修复缺陷之间的多任务切换导致的效率损失。 测试周期长，不能频繁执行回归测试，不能随时有信心重构代码，以保持灵活性。 测试团队膨胀，导致沟通管理成本变高。 相对而言，CI/CD，微服务，容器化属于基础设施，只需要部分人掌握即可，业务开发工程师只要学会使用，成本不高。但业务开发工程师必须学会编写测试代码和重构代码的技术。由于行业普遍缺乏基本功的现实，需要培养的人数众多，通过引入外部技术教练可以缩短培养周期，更快看到效果，但外部技术教练本身也很稀缺，在数字化转型的大潮中，价格也水涨船高，并且因为市场需求大，导致难以长期高投入度地服务于同一家企业。另外，由于行业特殊性，尤其金融行业的业务复杂度较高，外部教练也需要花时间熟悉业务才能指导业务开发，否则只能隔靴搔痒。 招聘市场竞争压力大 毕业生招聘市场压力大，优质学生被大厂高年薪争夺。 经验流失 企业内部的资深工程师，除了架构，技术管理，转业务，多年积累的丰富经验，可能不能得到很好的传承，加上上层的岗位数量有限，导致资深工程师人才流失。 建设内部教练队伍的好处： 支持数字化转型 用内部教练团队，通过开展培训和辅导，加速企业数字化转型。 用培养体系来降低选人门槛 技术人才培养一直是 HR 的难题，基于内部教练团队发展出技术人才的胜任力模型，课程体系和导师池，建立师傅带徒弟的培养模式，可以有效降低人才招聘的门槛。 雇主品牌 有内部教练团队，本身是一种工程师文化的体现，对于雇主品牌形象加分效果明显，更能吸引到优质的技术人才。 资深人才的多元化上升通道 资深开发人员，对业务和管理都不感兴趣，热爱培养他人，有了施展的舞台，也能够获得价值上的认可。更能留着这些经验丰富的资深人才，并且将他们的经验传承下来。
读到同事张逸的一篇博文：
记录 Seaborn 的工作，学习和生活，欢迎关注
刘炜问
第一：对于产品经理的工作，岂不是还是要针对需求做详细的描述和说明，那不就是将原先需求的名字换了一种写法而已？ 从组织形式来说，在传统的需求文档中，偏重描述系统应该长成什么样，很少提及我们为什么要做这个特性，用户在什么场景下要用这个特性，用了有什么好处。这样的话，团队就只看到解决方案，直接去实施解决方案，看不到「问题」，就可能造成：无法和业务方及用户共情，难以接受需求变更，无法在早期提出更高性价比的方案。 敏捷需求，最重要的变化是从「用户故事」出发，整个团队所有人都有机会首先站在同一个视角，就是用户视角来思考，从而就能理解为什么要做，为什么要改，为什么要先做这个后做那个。 总结一下就是：传统需求文档更注重描述解决方案，就是功能特性，业务规则等。敏捷需求更注重传递用户痛点，优先级，验收条件，实例。
最近，有一位前不久参加过入职培训的同事跟我说：
记录 Seaborn 的工作，学习和生活，欢迎关注
我兴趣非常广泛，什么都想学。 在学习上也没少花钱：
周末和同事去打桌球，突然觉得很熟悉的感觉。 仔细思考，发现它和我们每天做的软件开发是如此相似。
记录 Seaborn 的工作，学习和生活，欢迎关注
在上周的一场活动上，我作为演讲嘉宾，接受了一位听众的提问：对程序员来说，沟通表达能力有多重要？ 相信很多人对这个话题感兴趣，在此整理成文分享一下。
本文结构：
在我还是孩子的时候，父亲对我的要求很严厉。 早上起床不能太晚，印象中差不多是 8 点，起床后不能赖在床上，要立即穿好衣服，整理好床铺，洗脸刷牙......
Title: 坐火车 Date: 2014-03-17 23:59:23
记录 Seaborn 的工作，学习和生活，欢迎关注
记录 Seaborn 的工作，学习和生活，欢迎关注
记录 Seaborn 的工作，学习和生活，欢迎关注
记录 Seaborn 的工作，学习和生活，欢迎关注
记录 Seaborn 的工作，学习和生活，欢迎关注
我的观点是
记录 Seaborn 的工作，学习和生活，欢迎关注
献血这种事呢，没有什么大不了的，每天都有很多人在做，朋友中也有很多人都献过。但对我而言，却是大姑娘上花轿头一回，还是感触颇深，所以还是写出来，供还没有献出第一次的朋友参考。
我求职面试的经验不多，在创业期间，倒是积累了一些招聘面试的经验。
Title:精明的骗子 Date:2016-03-12 21:36:27
亲爱的老婆：
在培训时谈到单元测试，学员会有很多疑问，包括不认可，觉得成本过高，当然这方面我们是很有经验的，于是我们就会去和他们讲道理，期望能说服他们，却始终无法说服。 直到我们看到他们的单元测试，才知道我们说的根本不是同一个东西，他们说的单元测试是开发人员要自测，并且把案例和执行结果截图填到一个「单元测试报告」里。
关于函数调用开销，也是很多人担心的地方。 我认为有几个点可以交流： 首先，提取函数只是消除重复的一种方式，还有其他的方式，比如以下这个例子：
什么是翻转课堂
@Seaborn Lee 小波老师：关于估点？
记录 Seaborn 的工作，学习和生活，欢迎关注
Title: 透过「陀螺」看西安老炮儿 Date: 2016-06-22 08:37:47
Date: 2013-07-30 11:20:11 Tags: 翻译
Date: 2013-08-05 12:20:04 Title: 谈测试代码的可维护性-重复 Url: /talk-about-maintainability-of-test-from-duplication
Date: 2013-08-07 21:58:20 Title: 爱是一种选择-读《爱的五种语言》有感 Tags: 读书笔记,婚姻家庭
通过副标题「如何分派任务和承担责任」可知这是一本领导力类书籍。 职场中人或多或少都经历过书中的故事场景，比如一个专业能力很强的领导是如何让自己承担越来越多本应由下属承担的责任，自己越来越忙直到无法承受，而下属越来越没有成就感和驱动力，最终领导与下属互相职责抱怨。
<small>
1 在新的团队推敏捷的时候，作为敏捷教练，应如何提前做好计划呢？ 大概要考虑哪些维度呢？ 通常的步骤是：摸清现状，确定目标，找出差距，制定策略，度量调整。 现状可以从需求管理，团队协作，配置管理，质量保障四个维度去调研，各家公司都有自己都工具，比如 TW 的 「AMM」，优普丰的「精益敏捷平衡轮」； 和团队的领导，关键角色，业务方以及重要的干系人成立转型小组，一起共创要达到的目标； 用目标减去现状就是差距； 根据差距制定辅导的计划，比如提升透明度，加强流动，需求价值排序，需求拆解，单元测试等，落实到具体的时间阶段，引入外部专家资源等； 制定周期性回顾计划，转型小组一起回顾计划执行情况，调整改进。
记录 Seaborn 的工作，学习和生活，欢迎关注
我在 2015 年离开
nginx -t nginx -s reload
我觉得重构是很好的切入点：
1 其他公司的敏捷是怎么做的，做的好的是什么样子呢？好的点和不好的点可以举例说明一下吗？
需求变化是有害的
这是目前为止离病毒最近的一次了，小区出现了两例确诊，所在楼栋已上了铁板打围。小区所有人不得出小区，孩子也只能在家上网课。 想到网课，脑子里已经出现了鸡飞狗跳的画面。为了做得更好，给自己来几条纪律：
记录 Seaborn 的工作，学习和生活，欢迎关注
以下是领读活动准备的大纲：
为什么要做MVP？
有一张趣图：读书是为了能跟别人好好说话，健身是为了让别人能好好跟你说话。
看板上缺少一个「障碍」区，SM 开始找胶带，准备在最下方拉出一个区域来。 一位成员说：放在下面不容易看到吧？ SM：这个，只有 SM 看。
站会时，SM 问：为什么这三张卡还在这儿？ 这时，相关的几个人一顿解释，但怎么听起来都像辩解，没有人去挪动卡片。 结束后，我问：刚刚说这三张卡跟实际状态不一致，怎么才能让看板反应真实的状态呢？ 大家开始挪卡。
非常有影响力的一个 TED 演讲：
为什么企业要建设内部教练队伍？
你们团队的前后端工程师 是不是互相鄙视 是不是联调经常需要等待 是不是数据接口总需要返工 …...
有一次参加一位同事在办公室做的分享，觉得收获很大，结束后专门跑过去感谢这位同事。 「你今天这个分享很棒哦！」我说。 同事说：「谢谢小波老师夸奖，在小波老师面前班门弄斧了。」 我当时就感觉气氛有点尴尬，本来是去感谢同事的，但给人感觉是上级对下级的表扬和肯定，同事心里可能会有点不舒服。 哎，想赞美一下人，咋这么难呢？
培训是最值得投资的技能，掌握培训技术后，你可以把所有的特长都变成课程，帮助别人成长的同时还能获取不错的财务回报。 我并不是说每个人都应该成为整天飞来飞去的职业培训师。在职场中，很多做得好的人教不好，教得好的人做不好，如果你有一定的专业技能，那么学习一些培训技术，对个人的职业发展是很有帮助的。你将会比其他领导更擅长发展他人，影响他人。 最近在 ThoughtWorks 全国六个办公室轮番开启 TTT 课程，激发了许多同事对于培训的热情，为了帮助大家更快地走入培训的世界，推荐几本对我帮助很大，又很容易读的书。
作为讲师，为什么你想跟学员互动的时候，学员不愿意提问呢？
问
问：公司最近尝试敏捷开发和管理，但是没什么收效，实行了一个多月了，感觉和以前一样，该完成的完成不了，开发没有成就感，都没有一点的积极性了，难道是项目比较大不适合敏捷吗？是新项目，项目比较大，做了几个月后刚开始实行敏捷，每天早上组织 Team Leader 开会半小时，主要回顾昨天的工作中遇到的问题，是否需要决策，以及今天要完成的事情，需要什么支持，开发任务是按照周为单位布置的，每个开发和 Leader 细化，周五开会时间长一点，超过30分钟不能解决的问题就一起讨论。Leader 会在开会前收集各个成员的问题和事情。团队构成：PM->CTO 1 位 ->架构师 1 位 -Team Leaders（兼开发）6 位->Developers，开发和测设人员接近 30 人。
良好的习惯是人在其神经系统中存放的道德资本，这个资本不断增值，而人在整个一生中就享受着它的利息。
用如下命令：
第一次听说结对编程的时候，我觉得太反直觉了，两个人用一台电脑写代码，效率不就下降了一半吗？后来我在团队里去尝试引入结对编程，也没感觉有多好，而且小伙伴们的反馈也觉得不好，还是一个人写代码更自在，也就做了一周就放弃了。 直到 2012 年，第一次参加 Code Retreat 活动的时候，一天之内和日本人，德国人，英国人，美国人结对编程，不停地发出类似「哇哦，这道题目还能有这样的思路啊；哇哦，代码还能这么写啊；哇哦，原来 Vim 是这么用的啊」之类的感叹，让我对结对编程有了一点新的认识。 后来加入 ThoughtWorks 以后，结对编程变成了日常的工作方式，入职第一天，我就看到对面有两位一看发际线就知道很有经验的人在结对编程，充满了欢声笑语，一起去领取故事卡，一起去上厕所，一起去挪动物理墙上的故事卡。让我看得好生羡慕。后来在工作中，通过结对编程，我终于学会了如何做测试驱动开发，如何用 Vim，如何写 Rails 等等等等。到后来，我通过结对编程让别人学会测试驱动开发，学会 Vim，学会 Rails。 这些年，和形形色色的人进行过结对编程，有内向不说话的，也有外向霸着键盘的，有几十年编程经验的老手，甚至也有从未写过一行代码的新手。遇到过很多问题，也慢慢摸索出了一些门道，彻彻底底地爱上了结对编程。 我想分享一下我对结对编程的理解，消除对结对编程的一些普遍误解，影响更多的程序员朋友爱上结对编程，享受它带来的好处。我将从「是什么」，「为什么」和「怎么做」三个方面来展开。
记录 Seaborn 的工作，学习和生活，欢迎关注
一直写干货文章，第一次写软文，我的手指都在微微发抖，生怕被人看出来，偷摸儿的早上起来悄悄写。 是什么样的人，让我这样的硬汉甘愿为他软一次呢？ 他是我的偶像，我的老师。与其说是帮他推广今晚的幽默表达公开课，不如说是给我的朋友传递一个信息，让大家有机会了解幽默的奥义。 如果你今晚和周六都没空，没关系，继续看，看完还是没空算我输。
最近，看到越来越多当初一起写代码的程序员朋友，成为了 Team Lead，Tech Lead，Manager，Buddy，Sponsor，Coach，Trainer，Mentor。我一方面为他们感到骄傲，骄傲他们走出了舒适区，从一名单纯的程序员，走进了培养者的行列！另一方面也为他们感到担心，担心他们会和我刚开始那样 - 手足无措。
ThoughtWorks 在 2013 年被评为最难面试的科技公司，可见我们对人才的期望是很高的。随时业务的快速增长，招聘也成为了企业发展的制约因素。ThoughtWorks 把「积极提倡社会和经济公正」作为公司的第三大支柱。为了提升技术女性的就业竞争力，我们与一些具有创新精神的高校合作进行「卓越女生计划」，打造创新实验室，探索创新的人才培养模式。 去年 6 月，我加入了 ThoughtWorks 思沃学院团队，参与了很多教学工作。我想通过本文谈谈，在数字化时代背景下，企业对人才提出了什么样的能力期望，以及我们对人才培养模式的一些探索。
昨天跟大家分享了
有的人讲话重点清晰，有的人说半天你不知道他在说什么。 有的文章让人拍案叫绝，而有的却给人胡乱堆切文字的感觉。 有的演讲振聋发聩，而有的却不知所云。
我会的东西很多：
我们常常抱怨，低效的会议浪费了大量的时间，导致不得不加班才能完成工作。 在开会的时候，有人躲在角落玩手机，有人在窃窃私语，有人争得面红耳赤，有人拍完桌子愤然离场。 无效的会议是极大的浪费，我们迫切需要，一种更好的会议方式。
一转眼，我练习绘画有三十天了，首先祝贺一下自己，完成了又一个三十天挑战，这三十天一天都没有中断过，唯一遗憾的是，最晚的一天，是在十二点之后完成的。 现在回首这三十天呢，我觉得我经历了三个阶段：
昨天晚上听了一个知乎 Live 分享，价格是 10.24 元，非常极客范儿的一个数字，大概因为分享者姜志辉老师曾经也是一名程序员吧。 他自称「跨界疯人院院长」，运营着一个公众号和私密群。 他公众号的介绍非常有意思：
有些人工作时间不长，却经验丰富，做事老练。 有些人工作十年，却只是把一年的经验重复用了十年。 今天来说说，如何从经历中提取经验，倍速成长。
在读下面这段文字之前，请脑补 Rap 节奏，嗯嗯...哟...
人是经验动物，经验从哪里来？可以向别人学习，也可以向自己学习。 看书、听课，就是学习别人的经验。向自己学习，是自然而然发生的，比如被火烫过一次，就知道离火远一点。 反思，是刻意地向自己学习，最大化地从经历中提取经验。
昨天晚上，又一次参加了教练对话练习。 练习后，观察者给我反馈，说我提的问题有诱导性，不够中立，而教练应该是一面镜子。 我就一直在想，镜子是啥意思，到底要怎么才能做好一面镜子。 带着这个问题，我加入了另一组。 在练习结束后，作为观察者的张莹开始点评，他打开手机，展示了一张教练过程的照片。 我突然感觉被什么击中了。
我想要健康的身体，和谐的家庭，充满激情的工作，有效的社交。每天早睡早起，读书，写作，锻炼，不喝酒，不喝含糖饮料，不吃夜宵，掌握多种技能...
周一晚，小伙伴们相约在「灵感咖啡」，进行了一次教练对话练习。 我在练习中扮演教练角色，体验了「给建议」和「提问题」两种方式巨大的差别。
When talking about stand-up meeting, people probablely remember the 3 classic questions:
回成都后，银大伟看到我发的《如何交付一场企业内训 - 某客户 OO BootCamp 总结》 ，希望我和 Suncorp Health 团队 Tech Lead 尤青松一起，完成对其团队的培训。 最近在学习课程开发，借博客大赛，总结分享给大家。
去年不知道什么时候知道的
我从去年 8 月开始成为创业狗， 渐渐地参加俱乐部常规会议的次数越来越少。 因为我在公司成立了一个演讲俱乐部，名字叫「湾享会」。 我们从去年 8 月开始，每周三中午举办活动，到年前一共 22 次，从来没有中断过。 但是，过完年回到工作中时，我突然失去了激情，连再组织一次的勇气都没有。 有一位同事问了一句：我们什么时候还有「湾享会」啊？ 我觉得是时候停下来回顾一下了，到底哪里走错了。
用 IntelliJ TDD FizzBuzz 的详细步骤：
Code Style关注最终的代码，而Coding Style关注编码的过程。
一晃又是一年，一年短过一年。该来盘点一下这一年都干了点啥了。
4月16日，我在上海参加一个培训。下午培训结束，准备离开时，我实然发现我的钱包不见了。通常我的钱包要么在身上，要么在背包里。但就是遍寻不着。我并不是一个丢三落四的人，我开始回忆，最近一次使用钱包是吃早餐时付钱，之后就没再使用过。我相信有很大可能是落在吃早餐的面馆了。
不知道是年纪越大，时间过的越快，还是整个世界正在发生什么，使得时间真的过得更快了。
前两天Apple终于发布了稳定版的Yosemite，相信大家等了这么久，都第一时间开始升级了吧。 最近总看到有朋友在问一些升级的问题，因为我早在Beta版的时候就已经升级，经历过一些问题，写出来希望能对大家有些帮助。
前几天fork了Ruby China的源码，面对陌生的Ruby技术栈，一头雾水。 我fork它并不单为了学习，而是要在最短的时间搭建起我脑海中的社区网站。所以我不可能针对每一门新技术都去买一本书来读上半个月。
VIM用户可以使用宏来录制编辑动作过程，然后再播放以减少重复操作。 具体命令如下：
去年的某一天，收到客户的反馈说我们的产品在他的手机上不工作。 看了一下日志发现是WebView中JavaScript调用的某个Java方法找不到，通过报错信息搜索后得知：
小波是我们的特邀嘉宾，为什么邀请他呢？因为公司内有一句关于他的名言：“如果公司不提供支持，我就自己掏钱办这个活动“。而且我跟乔梁和路宁打过电话，他们都认识小波。小波虽然年轻，但能在社区中让这些人认识，我认为这也是一种才能。
记得一个朋友说过，如果只允许做Scrum框架中的一件事，那就做回顾会议。只要持续改进，任何团队都可以越来越好。回顾会议可以有效地识别问题，找到改进方法，只要经常回顾，每次改进一点点，团队就会越来越好。
这一年非常忙碌和充实，先来回顾一下比较有意义或者花时间精力比较多的事情。
把数据库中除指定的表外的其它表数据清掉，但要保留表结构。
上周和老同事饯行吃坏了肚子，一直拉了一周，而且从北京拉到了深圳。 刚和初次见面的同事吃完饭，一路上聊天，了解了一些公司的情况，以及客户和项目的情况。 现在坐在酒店里，是时候总结ThoughtWorks的这一周了。
谨以此文记录我进入ThoughtWorks的全过程,包括心理活动。
注：这是我写给ThougthWorks HR的邮件，也是第一次这么完整地总结自己的过去，觉得很有意义，纪念一下。以下是邮件内容：
一晃又快到老婆生日了，想起去年给老婆唱的生日歌。
通过面试后，hr给出面试反馈并告诉我进入thoughtworks后需要面对很大的压力-技术，工作方式，英语都需要持续地学习，让我好好想想第二天再答复，于是我当天中午就写了这封邮件给hr。不知道算不算求职信。 原文如下：
虽然接触TDD已有一段时间，但实践的并不多，所以理解也很浅。在此次活动中，很多同学是第一次接触TDD，也犯了普遍会犯的错误，比如先把所有测试代码全部写完才开始写实现代码，大粒度的测试和忘记重构等。网上也有很多关于TDD的争论，比如：
2012年1月4日，我做了上面这个全年计划。转眼一年就过去了，说好的末日也没有来，生活还得继续，所以还是要总结一下2012并做一个2013的计划，是吧。
核心价值：帮助大家通过阅读得到成长
小波，咱们的流程今天就告一段落了，你先回去，等过半年或者一年，觉得自己有比较大的进步后咱们再继续好吧。
本文是在公司内成立学习小组的动员信，原文如下：
其实早就准备好了域名和空间，直到今天才将Blog搭起来，并不是没东西可写（我的Evernote里也有259条笔记了），主要是觉得自己还不成熟，写的东西对别人没有价值。
记录 Seaborn 的工作，学习和生活，欢迎关注
sqlldr user/pwd@serviceName control=load.ctl