You are here

qyt 的blog

谁能干掉微信?

呵呵,标题党一下。微信对我来说就是多媒体短信工具和支付工具,公众号很少地关注了几个,朋友圈几乎不看。

去年见识了两个很火的设备。一个是微软的 HoloLens,一个是亚马逊的 Echo dot(其实主要是里面的 Alexa 智能助手)。HoloLens 的语音从头箍中输出,不需要戴上耳机效果也很好,Alexa 在语音开关灯、搜歌听音乐这些场景也很实用。

如果有一个类似 HoloLens 的头箍部分的设备,能进化到一个比较美观实用的样子,实现语音的输入输出,把这个设备蓝牙连上手机里的 Alex,那么脑洞就可以开了:
比如我想给 qyb 发条音频“微信”,我说:“Alexa,给 qyb 发语音‘微信’,明天中午一起吃饭。”
qyb 头上戴的“发箍”一震,传出“收到 qyt 的‘微信’”,qyb 说:“Alexa,读一下 qyt 的‘微信’”。
然后 qyb 就听到了我说的话,接着说“Alexa,给 qyt 发文字‘微信’,好的,明天中午 12 点老地方见。”
Alexa 先有一个反馈来确认语音正确识别为文字,“请问您的‘微信’内容是‘好的,明天中午 12 点老地方见。’?”
qyb 确认:“Alexa,是的”。于是我就收到了这条文字微信,当然我会让 Alexa 给我读出来,不会傻傻地掏出手机看。

如果这个流程顺畅,我看不出我有什么道理使用微信目前对我来说的文字或语音的短信功能?当然我还是要用微信,因为在这个工具上没有我的好友,这是腾讯最高的城墙,最深的护城河。但我认为这种设备是大家真正需要的可穿戴设备,以后一定是会出现的(骨传导耳机淘宝上有很多,虽然 HoloLens 用的似乎不是骨传导技术),它可以干很多很多事,比如记个备忘录设个提醒任务之类的,这些都是小儿科。如果腾讯自己不推出自己的“Alexa”,也一定需要让微信支持 Alexa/Cortana/Siri/Google Assistant 之类的智能助手。如果无视这个潮流,当人人都有一个“发箍”的时候,在手机上操作的微信一定会被别的应用取代。什么?你说微信支付、公众号、朋友圈?当一个公司有了人际关系自然就有了钱,有了钱就有了一切,腾讯不就是这样走过来的么?

当然,目前我觉得最大的可能是腾讯推出自己的“Alexa”(阿里刚出了一个智能音箱)。如果这个系统级、生态级的东西搞不出来/搞不起来,当发现事不可为,而 Alexa/Cortana/Siri/Google Assistant 等等渐渐壮大,相关的个人可穿戴设备市场上越来越多,腾讯会退而求其次把微信做成这些智能助手的应用。要知道亚马逊今年春天已经在 Echo 上推出了Calling and Messaging 服务,这两天又推出了一个叫做 Anytime 的即时通讯应用,等到亚马逊推出可穿戴版的 Echo 设备,Facebook、Snapchat 等等就要小心了。

最可悲的事是 Alexa/Cortana/Siri 将来被墙在外面(Google Assistant 不说了),中国公司又没有类似的平台,大家依然开心地用手机玩微信,中国与世界渐行渐远。。。

Topic: 

更换 Nexus 5 电池

1. 在淘宝上买了两块电池(希望效果不错吧),为什么买两块?手机就像电脑一样,从计算能力来说是越来越耐用了。

2. 用附送的工具拆下后盖

3. 用附送的工具拆下上下两个据说叫半总成的小片片

4. 用附送的工具(我用的是附送的小的一字螺丝刀,本来干这个活的蓝色小塑料片没两下就撬断了)取出电池(我看到还有一个小吸盘,我估计是用来辅助的,我没用上)

5. 装入新电池,装上半总成,拧上螺丝钉,合上后盖。

Topic: 

HoloLens 脑洞

《三体》里面有一个描述,当主人公冬眠醒来后,全世界到处都是屏幕。

这两天借了 HoloLens 玩了玩,脑洞开了很多。其中之一就是微软若干年后像现在亚马逊便宜卖带广告的 Kindle 一样便宜卖 HoloLens。然后派人把各个公共场所,什么医院、体育场馆、商场之类的地方的墙上都贴上虚拟的屏幕,上面放上针对性的广告。谷歌的 AdWords/AdSense 危险了。

Topic: 

京都-奈良-大阪 自由行

已经从日本回来,大概记录一下行程吧。

6 月 18 日下午坐国航飞机飞到关西机场,下飞机后首先设好淘宝买的 docomo 卡,8 天无限流量上网,关掉手机上的影梭 app。然后去机场 JR 站买 ICOCA 卡,用来在京都、奈良、大阪这几个地方坐各种电车、公交车、地铁、城铁等等。由于到机场时间已经较晚,所以之前在淘宝上就租好了一辆车,直接送我们去第一个目的地京都。0 点左右到达 airbnb 上订的民宿,一个两层木质结构的小楼。街口的 LAWSON 便利店营业中。

6 月 19 日到岚山坐观光小火车,虽然下雨,但也算有别样的体验。

6 月 20 日先徒步到住处附近的二条城参观,原来是德川幕府在京都的寓所。然后去清水寺,下了地铁后,有一段上坡路,两边都是店,边往上走,边觉得这怎么这么像香山啊。清水寺人不少,也像香山。出了清水寺去伏见稻荷大社,到的时候已经是四五点了,人都在往外走,所以里面人不多,感觉不错。

6 月 21 日从京都到奈良,没有计划在奈良住,目标就是逛逛奈良公园。鹿就在路边上,买了鹿吃的一叠薄饼,瞬间被鹿包围了,都是长角的大鹿。由于饼上还有纸条系着,就在拆纸条的时候,鹿已经等不及了,纷纷开始咬我,被咬了四五口后,终于大腿上挨了一口狠的,手一松,饼掉在地上,你们自己吃吧,不陪你们玩了。到无人处查看了一下,幸好没有创口,后来就紫了,至今未变成鹿人甲。进了公园里面后,鹿随处可见,不过都是一两只的规模,所以可以放心的喂鹿。公园里面草多,树多,人少,感觉非常好。下午四五点离开奈良去最后的目的地大阪。在大阪住的也是 airbnb 上订的民宿,高层公寓 16 楼,楼下就是 JR 车站和地铁站。晚上走到梅田去吃一蘭拉面,排了半天队,吃到后觉得队果真没有白排。

6 月 22 日大阪环球影城,哈利波特禁忌之旅确实值得一玩,相当于坐一个缩减版的过山车(没有倒过来)戴上 3D 眼镜,哈利波特骑着扫帚在前面带着你在电影里的场景中飞,什么霍格沃茨学院的城堡啊,魁地奇球场啊,摄魂怪啊之类的,在城堡里飞的时候总觉得脚会碰到建筑物上,不由自主地把脚尖往上提提。刺激归刺激,但很难入戏,因为哈利同学说日语!在环球影城里转悠各个项目的时候,一直有点淅淅沥沥的雨,时停时下,到后来下大了,被淋了半湿,幸好没有生病。

6 月 23 日心斋桥逛街,下了地铁都不用问路,普通话的密度从小变大就是方向。任何大城市购物的地方都差不多,对于淘宝族来说没怎么逛就放弃了,去街里面的王将连锁店吃了个招牌炒饭,味道很好。

6 月 24 日先去了大阪城公园,里面的大阪城遗址据说是丰臣秀吉的居所,其中的天守阁也是烧了建,建了烧,让我想起了黄鹤楼,没上去逛,赶紧去计划中的海游馆。据去过珠海长隆海洋王国的人来说,这个海游馆着实一般,但是对于只去过北京的海洋馆的我来说,这已经很好了,各种鱼,很大,就在眼前游过。特别是人不多,可以坐在椅子上慢慢看。刚准备出馆,外面一阵瓢泼大雨,于是先避了一会雨,雨基本上停了,感觉很冷,怕生病,买了一件短袖穿上。接着坐了旁边的摩天轮,全透明的车厢。整个摩天轮只有 4 个全透明的车厢,不过感觉 60% 的人都在等着坐,估计还有 20% 的人是实在不想等了才坐普通的车厢。

6 月 25 日到关西机场后,先去机场 JR 站退了 ICOCA 卡,然后坐国航的飞机回国,飞机餐比来时好吃,听旁边的人说去日本是国内配餐,回中国是日本配餐,所以有差别,不知真假。

流水帐到此记录完毕,总体来说,日本是一个和谐的国家,可惜打开 uber,没看到一辆车。

再记几点:

1. POS 机的底部都有两个前脚,这样按密码时更方便也更私密。

2. 住的两个地方都是浴室、洗漱间、厕所分开。

3. 住的两个地方的抽水马桶的储水缸上面都有一个水管和一个小的洗手池,一冲水,水管就流水,洗了手后的水就流到下面的储水缸里一点也不浪费。

4. 厕纸质量差于国内,还有的是单层的,估计是为了环保。

5. 没看到日本人打折叠伞。

6. 看到的几个在路边接电话的日本人都在用翻盖手机。

Topic: 

django 1.9 i18n 国际化和本地化

网上一堆讲 django 国际化与本地化的文档。不说太多。

django 1.9 以后(也有可能是 1.8 以后),zh_CN/zh_TW 不推荐用了,改为 zh_Hans/zh_Hant,这个作为 locale 下的文件夹名。

在 settings.py 文件里,用 LANGUAGE_CODE = 'zh-hans' 或 LANGUAGE_CODE = 'zh-hant' 似乎是官方推荐的。(注意这里是连字符,文件夹是下划线)

我碰到的问题是,用 django-admin makemessages -l zh_Hans 后,能够在 app_name/locale 下面生成 zh_Hans 文件夹及对应的 po 文件。编辑文件后,用 django-admin compilemessages,能把 po 文件编译出对应的 mo 文件,但是网页上死活出不来中文。

settings.py 里 'django.middleware.locale.LocaleMiddleware', 这句也加在 MIDDLEWARE_CLASSES 里了,USE_I18N、USE_L10N 默认就设为 True,也没改过。折腾半天,有个网页说有可能是 django 找不到 locale 的位置,需要在 settings.py 里写出来,于是加上:

LOCALE_PATHS = [
    os.path.join(BASE_DIR, 'app_name/locale'),
]

搞定!

另外目前 Django REST Framework 好像还不支持 zh-hans 这样写。

Topic: 

dup2.com 上线全局邮件存档功能

邮箱管理员可以给自己管理的域设一个用来存档的 email 地址。
当这个 email 地址验证通过并开启存档开关后,这个域所有的出入 email 都会被密送(暗送)到这个用来存档的 email 地址上去,达到全局邮件存档的效果。

Topic: 

Django REST framwork 报 NOT NULL constraint failed 的处理

我碰到这个问题由来是,在某个 model 里,foo_id、bar_id 两个字段都是别的表里的外键,但是在 serializer 里我又不想显示 foo_id,而想显示 foo_id 所代表的真正的意义

  1. class FooBarRelationshipSerializer(serializers.HyperlinkedModelSerializer):
  2.     foo = serializers.SerializerMethodField()
  3.     bar = serializers.CharField(write_only=True, required=False)
  4.     def get_foo(self, obj):
  5.         return Foo.objects.get(pk=obj.foo_id).name  # foo_id 来自 urls.py 里的相关 router 的定义
  6.     def validate(self, data):
  7.         del data['bar']
  8.         return data
  9.     class Meta:
  10.         model = FooBarRelationship
  11.         fields = ('foo', 'bar')

通过上面这段代码能很好地达到我的目的。好,问题来了,我想把 foo_id 和 bar_id 的关系存入表中,如果用 foo_id 和 bar_id 的话,request.data 里必然存在输入的 bar_id,但是我的实际输入是 bar,我必须要重载 validate 方法,把 bar 去掉,那么我在 views.py 里手动把 bar 对应的 bar_id 取到,然后塞进 request.data 里好了。然后

  1. serializer = self.get_serializer(data=request.data)
  2. if serializer.is_valid(raise_exception=True):
  3.         serializer.save(foo_id=foo_id)

想得挺好,运行时却报了 NOT NULL constraint failed 的错!!!

网上搜了半天,没有什么结果,提供的答案都是告诉你检查一下是不是有必填的字段没有给数据。但真正碰到这个问题的,而且还寄望通过搜索解决问题的,基本上都会先保证必填的字段里有数据,可现在数据都有了,为什么还会报这个错???

我打印了 FooBarRelationshipSerializer 里用 foo_id 和 bar_id 时的 request.data 和现在的 request.data,里面的数据一模一样!!!但是就是前者的 serializer.save 能成功,后者报错。。。

思来想去,可能同样的 request.data,但经过 serializer = self.get_serializer(data=request.data) 后,serializer 会不同,谁知道 get_serializer 里有什么鬼(不看源码了)。尝试直接把 bar_id 作为参数传给 save 方法,就像这样 serializer.save(foo_id=foo_id, bar_id=bar_id),结果当然是成功存入数据库。哈哈。

Topic: 

Django REST framework serializer 跟 model 无关的只写(write_only) field 的处理

有时候想在 DRF 的 api 里塞一些跟 model 无关的,但又是必须要处理的数据,比如设密码时,为了保证输入无误第二次输入的 password,这种信息一般设为只写。
这个时候 serializers.py 里,把 validate 方法重载一下,在里面删掉 request.data 里实际上 model 不需要的数据就 ok 了。

  1. class AccountListSerializer(serializers.HyperlinkedModelSerializer):
  2.     password = serializers.CharField(write_only=True, style={'input_type': 'password'})
  3.     confirm_password = serializers.CharField(write_only=True, style={'input_type': 'password'})
  4.     def validate(self, data):
  5.         del data['confirm_password']
  6.         return data
  7.     class Meta:
  8.         model = Account
  9.         fields = ('password', 'confirm_password')

当然,在 views.py 里,需要校验一下 password 和 confirm_password 是否输入了,如果输入了,是否一致

  1. if not request.data.get('password') or not request.data.get('confirm_password'):
  2.     raise serializers.ValidationError("Please input password and confirm it!")
  3. if request.data.get('password') != request.data.get('confirm_password'):
  4.     raise serializers.ValidationError("Passwords do NOT match!")
Topic: 

Django REST framework serializer 跟 model 无关的只读(read_only)field 的处理

有时候想在 DRF 的 api 里塞一些跟 model 无关的信息,比如一些提示的信息,这种信息本身跟业务没有关系,设为只读。
这个时候 serializers.py 里:

  1. class FooSerializer(serializers.HyperlinkedModelSerializer):
  2.     foo = serializers.CharField(read_only=True)
  3.     tips = serializers.CharField(source='get_tips', read_only=True)
  4.     class Meta:
  5.         model = Foo
  6.         fields = ('foo', 'tips')

这个时候 models.py 里:

  1. class Foo(models.Model):
  2.     foo_id = models.AutoField(primary_key=True)
  3.     foo = models.CharField(max_length=128)
  4.     def get_tips(self):
  5.         return 'Please foo bar.’
  6.     class Meta:
  7.         db_table = 'foo'
Topic: 

dup2.com 上线邮件组功能

邮件组的可投递级别分为 4 个级别:
0 - 无限制(任何人都能往邮件组发信)
1 - 同一域名内的 email 地址和白名单中的 email 地址可以往邮件组发信
2 - 邮件组内 email 地址和白名单中的 email 地址可以往邮件组发信
3 - 仅白名单中的 email 地址可以往邮件组发信

Topic: 

页面

Subscribe to RSS - qyt 的blog