Category: Uncategorized

  • 给开始在日本学习生活的人的一点参考:在日本看病(2)

    上篇大致讲了一下在日本看病的常识。小毛小病在诊所能解决掉是最好的,不过有些必须去医院,比如我昨天做的拔智齿的手术。 本文主要是记录自己拔智齿的前后过程,顺带讲一下医院与诊所的不同。 前篇中也提到过,如果直接去医院,也就是是紹介状なし(しょうかいじょうなし,没有介绍信)的情况下去的话,会收额外的一笔不少的费用。所以建议先在诊所看病,如果不行的话,可以让诊所开介绍信,你再去医院。 这次我就是親知らずの抜歯(おやしらずのばっし、拔智齿),需要动手术,歯科(しか、牙科)帮忙开了介绍信。注意开介绍信也是要费用的,但是比没介绍信直接去医院要便宜。我拿到的介绍信是一个信封,上面给你指定了医院,科室和医生。信封里面的内容我没有确认,估计就是你在这家诊所的病例卡。

  • 给开始在日本学习工作的人的一点参考:在日本看病(1)

    最近到医院预约了拔智齿,突然想到对于一个到了人生地不熟的日本,而且不喜欢抱团的人来说,如何在日本学习或者工作的同时看病是一个很大的难题。语言是一方面,日本和国内大相径庭的看病方式也需要时间适应。所以,考虑了下,分享顺便也记录下自己的看病经历。 到现在为止,个人经历过的主要是皮肤科(皮膚科、ひふか),牙医(歯科、しか)。个人体质原因,不大感冒,没去过耳鼻咽喉科(耳鼻咽喉科、じびいんこうか)。不过今年春天好像得了花粉症(花粉症、かふんしょう),可能之后会去。 和国内不同,小毛小病这边不会去医院(病院、びょういん),而是先去诊所(クリニック)。直接去医院的话,会额外收一笔费用,而且你会等很长时间。

  • 登山笔记(序)向山进发

    从小到大没爬过几次山。 印象里最深的是小时候春秋游去过南昌梅岭和三清山,高中时浙江仙居上海佘山和大学里暑期调研的泰山。但这些都是旅游景点并非所谓的山,我甚至说不出这些景点内山的名字。想去爬山玩?门票价格摆在那里。所以从来没有对登山产生过兴趣。 然而看过ヤマノススメ后才知道在日本登山是用不收门票钱的。 刚来日本半年后某个周末的上午躺在地上,想想自己一个人平时周末除了打游戏就是看动画,不如出去走走。然后就穿上普通运动鞋和轻便的服装开始了场圣地巡礼。 高尾山,来日本旅游的话绝对推荐去走一圈的山,在东京都内交通方便。没有登山装备可以简单从一号路的水泥路上去,想体验水路的可以走走六号路。 高尾山附近一带大多是这类泥地的山,适合散心。想稍微锻炼一下体力的则可以往丹沢箱根方向走。 不知不觉已经走过了很多地方,不知不觉买了一堆户外用品。留下一堆遗憾和一堆回忆。 不知道什么时候能去長野県来一圈纵走,或者在山上搭个帐篷看星空。如果养了阿猫阿狗的话,好想带着它们去爬山。 爬山回来后洗个澡睡的像猪一样,闭上眼睛就能看到满是石头的地面,好像还在摇头晃脑走着山路一样。 希望今年能在富士山上看到御来光。

  • Raft实现笔记-开篇

    本系列是在实现了绝大部分raft论文中描述的功能之后实现过程中遇到的问题,设计的决策等的记录。随着功能的增减,项目的逐渐完善,系统中的实现笔记可能会有偏差,但是基本上对于第一次实现或者想要理解raft的人来说可以作为一个参考。 现在,2018-08-09已经实现的功能 leader election + log replication membership change(one server change) log compaction(snapshot)

  • [DSL]模式匹配与请求跳转

    [DSL]模式匹配与请求跳转

    具体上次撰写博客有一段时间了。这段时间内自己学些了很多,想了很多,尝试去理解了很多。结果之一是不管这个博客是为了什么而建立的,我还是把自己的技术思考记录下来。 本文描述是自己在工作中实现的一种DSL。DSL是个人今天年初左右才决定的发展方向,只是在具体工作中使用还是第一次。希望这可以作为自己在技术上选择性发展的一个好的开端。 由于是工作中开发出来的一种DSL,所以不会讲太具体的业务场景,而是以技术设计与实现为主。 本DSL的设计目的的核心如题,模式匹配和请求跳转。结合起来就是按照某种业务规则以模式匹配的方式决定请求是否跳转。更直接的一种表达方式是if else决定是否要redirect,只是这段if else是用DSL定义的。 使用DSL定义规则的好处在于更清晰地展现跳转的条件,避免技术实现给业务规则辨识带来的”噪音”,特别是复杂的跳转规则。其次是快速支持规则的变化,比如易变(不管是运行时易变,还是需求期易变)的规则,附带的另外一个好处是如果业务上需要动态定义的话,DSL可以快速支持,不再需要通过数据库设计,配置等传统方式。

  • rsync与fabric

    接上篇。 最近学习rsync,突然想到自己之前使用fabric上传工程时与其用tar上传再解压缩还不如用rsync增量传输,后者可以更快。查了下fabric的文档,发现有提供几个方法: fabric.contrib.project.rsync_project(*args, **kwargs) fabric.contrib.project.upload_project(local_dir=None, remote_dir=”) 第一个就是使用rsync,第二个其实和我之前的方法一样采用压缩包传输的。rsync_project个人认为实际上就是local(“rsync xxx”)的模板,参数并不是很全。 但是使用了之后我还是考虑使用第二个方法upload_project,原因是rsync和fabric的ssh登录是分离的:rsync_project需要我重新输入一次密码,不输入的话就需要退化成local加上sshpass。再考虑到一开始可能没有输入密码,代码可能会变成这样: rsync_cmd = ‘rsync –exclude=.git –exclude=*fabfile* -pthrvz . -e ssh %s:source’ % env.host_string if env.password: local(‘sshpass -p %s %s’ % (env.password, rsync_cmd)) else: local(rsync_cmd) 如果不想输入两次密码的话,就必须在代码上或者命令行上写上密码,不是很安全。考虑再三,还是使用fabric提供的upload_project,虽然压缩可能慢一点。