效率

上次的paper deadline，我发现了一个非常惊人的趋势，除了午睡和晚餐，我就在不停写paper.

红色部分休息，其他部分都在工作。占大部分的浅褐色部分是winedt,写latex用的，和褐绿色是pdf viewer。非常惊人。自己也被自己惊叹道。

于是乎发现, 我是个deadline-driven 的人。

平常是effectiveness是80%，deadline的effectiveness（不算午睡和晚餐）是爆频，几乎100%。

现在想的是天天重现100%效率。。。

那种deadline-driven 的focus 必须要找回来呀。

日本

最近常常都把所思所想集中在onenote里，所以能搬上台面的也少了。
好像有段时间也没写了，于似乎又回来写写。

最近刚从日本回来。

日本，身处哪里的时候，我有时觉得我在台湾，有时觉得我在韩国，因为这些国家都有很多的日本影子。台湾被日本殖民五十年，韩国日本也是邻居。然后我就不断告诉自己，我在日本我在日本，把自己20多年来看过的电视电影中的日本扯上关系。东京街道，和fast and furious里的东京是一个风格。那种典雅的日本tatami，小屋风光，也不是到处都是，主要的还是城市的高楼大厦、钢骨水泥。

以前日本是一个想去的地方。不过现在貌似是去了一次之后就接踵而来的趋势。就像以前从来没坐过飞机，但是坐了一次之后，就没停过了。

东京的时候，住在一个superior double的房间，没人住了让给我们的，确实不错。外面是东京街道。京都则住在一个airbnb小屋子内，还可以。

日本最引人入胜的，是它的国民优先的制度 - 最好的都先留给国民。另外，很多设计都很贴心、人性化。厕所马桶很高级。柜台收钱找钱都是自动的。日本人民普遍有礼貌。街道普遍干净。

这次游东京、京都、奈良。还是不错的。对了，当高铁路经富士山时，我仿佛感受到了大山的存在。我google map上一查，大山就在我的左边，于是往哪里看去，白雪好漂亮。但是才十秒钟，火车进地道，没了。。回程的时候也没有经过。就十秒钟的回忆。

下次好期待富士山。

新年愿望

给了自己一个新年愿望，这里就省略了是什么。

发现每个人都会依着惯性往前走。到了这个时刻，和以前同样的赶paper的时候，是同样一个状态。尝试把所有东西的delay。而中间delay的东西，有些是极具价值的。必须要把这些极具价值的东西掌握住，要不然这一年又是一次重蹈覆辙。

另外呢，在做research的同时，常常犯同样的错误。比如说：
1. 做完一个大module再做另一个。。正确是针对一个小的example,横向开发，fail fast，而且还能更早获得feedback..这个领悟和敏捷的概念有点像。
2. 喜欢东一点西一点的做。。应该集中在一个点上，减少overhead.
3. 跟着潮流做。。这个没错，但是必须要differentiable，才会引起人的注意。
4. critical thinking很重要。这个世界众说纷纭，你要相信大家说的都是错的。毕竟很大概率上这个是成立的。什么是对的呢？只有在你无法把它扳倒的时候。
5. 要相信自己的力量是非常非常有限的，要想着怎么去合作。
6. 还有一点，我感觉赶paper的时候进度特别大，而平常的时候，比较小。我觉得有必要思考原因。

我们需要很逻辑的去思考什么是最终的objective，什么是达到逻辑最蠢但却能用的方法。然后思考下一步能干嘛，接着马上行动。

除了物质最求，心灵方面其实跟重要。
纪律，专一，少点欲望，多给别人带来阳光
都是需要学习的。

时间管理 ManicTime

最近用了ManicTime,感觉对自己的时间运用有了更深刻的认识。
午饭 (40 min)+午睡(1.5 hours)+晚饭(20 min)+早午晚 上网时间(40 mins) 差不多就三小时。
帮忙debug的时间其实也挺多的，这意味着必须要花时间做教育，让团队培养起更好独立思考习惯。
再来是自己coding和design的时间，是占了一半以上，但是其实并没有想象的多。

Coding 方面
==========
建立模块，方便调用
写Todo list 的时候以actionable items 为基础
一般研究方面的东西适合横向迭代，有问题可以提早发现
马上行动

吸引法则

我发现 这个世界 大部分的时候 不适合逼别人做什么 而是吸引别人做什么 从这个点下手比较合适。
这适合于很多层面

做学术，爱情，等等都适用。
像商业，吸引投资人、吸引客户等等。
像网站，吸引大家来用你的服务。

就像一个磁铁，重点是如何增加磁性。下手点是对你的吸附物有了解，制造价值，被perceived的价值越大 （易用/相处，为自己创造更多未来价值，等等），吸附能力越强。

另外一个重点是如何用你有的有限资源来增加足够量的磁性。

口诀

说话时：想清楚objective
看定理时：看着 concrete example

backlog: c# vs typescript

Cons of Typescript compare to C#

1. var myStatement1=require("ast/myStatement")
and need to correct back to
var myStatement=require("./ast/myStatement")
C# does not have this problem

2. Refactoring of class won't affect the naming of usage of class in the other files
e.g., naming myStatement to myStatement1,
it will change from
var myStatement=require("./ast/myStatement")
to
var myStatement=require("./ast/myStatement1")
still myStatement is using
C# does not have this problem

3. The Test Explorer needs to parse for a long time, C# is fast

4. The compiler scanning each typescript file takes quite for a while during starting while C# is very fast

5. C# has windows form for fast UI prototype

6. The Typescript UI sometimes just hang, C# does not have this problem

7. The solution Explorer sometimes left with a big gap after cleaning the js and js.map file, C# does not have this problem

8. Many datastructure are lack off, and difficult to see the contents like Dictionary (from https://github.com/basarat/typescript-collections) in debugging mode. C# does not have this problem

Cons of C# compare to TypeScript

1. Need to go through Edge.js for running node.js indirectly.

2. Lack of understanding of JavaScript by always coding in C# (Fortunately I have coded quite sometimes in typescript).

3. Actually there is no real shortcoming of C#, it enables fast development without concerning on those superficial stuff, and put real concern in logic.