今天早饭时读了这篇文章。引用文章中的两个图表:

知乎用户中一线城市用户占较大的比重,北上广深皆在词云的中心位置(文字越大,比重越大)。

全国(全球?)都有哪些地方的人在玩知乎

知乎用户居住地前十名依次是:北京、上海、杭州、成都、南京、武汉、广州、深圳、西安、重庆。

知乎用户居住地前十名

显然在分析的时候是有需求将柱状图的量级关系和其它图表的语义关联起来表达分析结论的。

所以我们在处理可视化框架的时候,采用联动设计就显得非常有必要:比如在词云中鼠标覆盖北京的时候,下面的柱图中相应的柱子可以高亮显示,以提示用户其中的关联结论。

有的时候,这样的关联也许还不够好,还需要将两种图式叠加在一起显示,比如在地图的热力图基础上进一步显示柱图。

在网页上,一方面固然要求组件化设计,另一方面也意味着,这些组件是真“组”件,是可以被拆成零件的。

今天看到KNIME的产品介绍,差点灵魂出窍。不过冷静下来仔细一想,发现还是跟Canvas定位不太一样,它更偏向我早期接触的Clementine。查找Clementine这个词的时候,才赫然发现,居然2007年的网页上,就有KNIME的介绍了(虽然360的东西让我怀疑是不是有作弊)。

但KNIME也向我们示意了至少一个事实:工作流的功能在分析类软件中是有位置的。这让我对于最近我们开发中设计工作流的功能有了一个新的认识角度。

之前一直在考虑是引入一个成熟的引擎来搞,还是自己搭建一个朴素的轻量级的YY,委实难以取舍。之所以是用“YY”,一方面是说有些自以为是,另一方面是说其实还真没想清楚是个啥。“轻量级小引擎”?怎么个“小”法?怎么个“轻”法?不明就里。

但工作流显然是分析功能的基础设施,这一点却不仅仅是“昭然若揭”,反而像是“理所当然”了。


KNIME的关注点还是数据处理过程,它似乎更像是一个ETL工具,或者说,它在类ETL方面的功能上倾注了更多精力。但在数据可视化方面作为较少,不是一款实时在线分析。

换句话说,在国内市场更注重实际场景应用的情况下,KNIME还不够傻瓜。

目前来看,设计中的主要疏失在于:需要编写使用场景故事。我们引入了一种新的交互方式,但该方式如何具体运作,被给出细节刻画,简单说,缺乏“镜头”。需要镜头草图(分镜脚本),并用脚本串成一个功能的完整场景说明。

上午在讨论接口方案时,也涉及到表单交互上的细节。导致没发现接口设计中存在的模糊点,也是架构设计中未深入研究的层面:当提交保存时存在多个实体有关联关系,并且不同实体的增删改操作不同,为保证关系完整正确,需要同事务处理。


结合最近写冷数据文档的经验:

  • 故事梗概——战略设计
  • 人物设置——用户代表
  • 故事梗概——场景设置
  • 分幕剧本——用户故事
  • 分镜头——内容设计和使用场景
  • 灯光舞美——数据结构设计
  • 台词对白——接口设计
  • 排练彩排——单元测试

centos7安装mariadb:

# yum -y install mariadb mariadb-server
已加载插件:fastestmirror
Loading mirror speeds from cached hostfile
* base: centos.ustc.edu.cn
* extras: centos.ustc.edu.cn
* updates: centos.ustc.edu.cn
软件包 1:mariadb-5.5.56-2.el7.x86_64 已安装并且是最新版本
正在解决依赖关系
–> 正在检查事务
—> 软件包 mariadb-server.x86_64.1.5.5.56-2.el7 将被 安装
–> 正在处理依赖关系 perl-DBI,它被软件包 1:mariadb-server-5.5.56-2.el7.x86_64 需要
–> 正在处理依赖关系 perl-DBD-MySQL,它被软件包 1:mariadb-server-5.5.56-2.el7.x86_64 需要
–> 正在处理依赖关系 perl(Data::Dumper),它被软件包 1:mariadb-server-5.5.56-2.el7.x86_64 需要
–> 正在处理依赖关系 perl(DBI),它被软件包 1:mariadb-server-5.5.56-2.el7.x86_64 需要
–> 正在检查事务
—> 软件包 perl-DBD-MySQL.x86_64.0.4.023-5.el7 将被 安装
—> 软件包 perl-DBI.x86_64.0.1.627-4.el7 将被 安装
–> 正在处理依赖关系 perl(RPC::PlServer) >= 0.2001,它被软件包 perl-DBI-1.627-4.el7.x86_64 需要
–> 正在处理依赖关系 perl(RPC::PlClient) >= 0.2000,它被软件包 perl-DBI-1.627-4.el7.x86_64 需要
—> 软件包 perl-Data-Dumper.x86_64.0.2.145-3.el7 将被 安装
–> 正在检查事务
—> 软件包 perl-PlRPC.noarch.0.0.2020-14.el7 将被 安装
–> 正在处理依赖关系 perl(Net::Daemon) >= 0.13,它被软件包 perl-PlRPC-0.2020-14.el7.noarch 需要
–> 正在处理依赖关系 perl(Net::Daemon::Test),它被软件包 perl-PlRPC-0.2020-14.el7.noarch 需要
–> 正在处理依赖关系 perl(Net::Daemon::Log),它被软件包 perl-PlRPC-0.2020-14.el7.noarch 需要
–> 正在处理依赖关系 perl(Compress::Zlib),它被软件包 perl-PlRPC-0.2020-14.el7.noarch 需要
–> 正在检查事务
—> 软件包 perl-IO-Compress.noarch.0.2.061-2.el7 将被 安装
–> 正在处理依赖关系 perl(Compress::Raw::Zlib) >= 2.061,它被软件包 perl-IO-Compress-2.061-2.el7.noarch 需要
–> 正在处理依赖关系 perl(Compress::Raw::Bzip2) >= 2.061,它被软件包 perl-IO-Compress-2.061-2.el7.noarch 需要
—> 软件包 perl-Net-Daemon.noarch.0.0.48-5.el7 将被 安装
–> 正在检查事务
—> 软件包 perl-Compress-Raw-Bzip2.x86_64.0.2.061-3.el7 将被 安装
—> 软件包 perl-Compress-Raw-Zlib.x86_64.1.2.061-4.el7 将被 安装
–> 解决依赖关系完成

依赖关系解决

=================================================================================================================
Package 架构 版本 源 大小
=================================================================================================================
正在安装:
mariadb-server x86_64 1:5.5.56-2.el7 base 11 M
为依赖而安装:
perl-Compress-Raw-Bzip2 x86_64 2.061-3.el7 base 32 k
perl-Compress-Raw-Zlib x86_64 1:2.061-4.el7 base 57 k
perl-DBD-MySQL x86_64 4.023-5.el7 base 140 k
perl-DBI x86_64 1.627-4.el7 base 802 k
perl-Data-Dumper x86_64 2.145-3.el7 base 47 k
perl-IO-Compress noarch 2.061-2.el7 base 260 k
perl-Net-Daemon noarch 0.48-5.el7 base 51 k
perl-PlRPC noarch 0.2020-14.el7 base 36 k

事务概要
==================================================================================================================
安装 1 软件包 (+8 依赖软件包)

总下载量:13 M
安装大小:62 M
Downloading packages:
(1/9): perl-Compress-Raw-Bzip2-2.061-3.el7.x86_64.rpm | 32 kB 00:00:00
(2/9): perl-Data-Dumper-2.145-3.el7.x86_64.rpm | 47 kB 00:00:00
(3/9): perl-Compress-Raw-Zlib-2.061-4.el7.x86_64.rpm | 57 kB 00:00:00
(4/9): perl-IO-Compress-2.061-2.el7.noarch.rpm | 260 kB 00:00:00
(5/9): perl-Net-Daemon-0.48-5.el7.noarch.rpm | 51 kB 00:00:00
(6/9): perl-DBD-MySQL-4.023-5.el7.x86_64.rpm | 140 kB 00:00:00
(7/9): perl-PlRPC-0.2020-14.el7.noarch.rpm | 36 kB 00:00:00
(8/9): mariadb-server-5.5.56-2.el7.x86_64.rpm | 11 MB 00:00:01
(9/9): perl-DBI-1.627-4.el7.x86_64.rpm | 802 kB 00:00:01
——————————————————————————————————————-
总计 9.0 MB/s | 13 MB 00:00:01
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
正在安装 : perl-Data-Dumper-2.145-3.el7.x86_64 1/9
正在安装 : perl-Compress-Raw-Bzip2-2.061-3.el7.x86_64 2/9
正在安装 : 1:perl-Compress-Raw-Zlib-2.061-4.el7.x86_64 3/9
正在安装 : perl-IO-Compress-2.061-2.el7.noarch 4/9
正在安装 : perl-Net-Daemon-0.48-5.el7.noarch 5/9
正在安装 : perl-PlRPC-0.2020-14.el7.noarch 6/9
正在安装 : perl-DBI-1.627-4.el7.x86_64 7/9
正在安装 : perl-DBD-MySQL-4.023-5.el7.x86_64 8/9
正在安装 : 1:mariadb-server-5.5.56-2.el7.x86_64 9/9
验证中 : perl-DBI-1.627-4.el7.x86_64 1/9
验证中 : perl-Net-Daemon-0.48-5.el7.noarch 2/9
验证中 : perl-Data-Dumper-2.145-3.el7.x86_64 3/9
验证中 : perl-PlRPC-0.2020-14.el7.noarch 4/9
验证中 : 1:perl-Compress-Raw-Zlib-2.061-4.el7.x86_64 5/9
验证中 : perl-Compress-Raw-Bzip2-2.061-3.el7.x86_64 6/9
验证中 : 1:mariadb-server-5.5.56-2.el7.x86_64 7/9
验证中 : perl-IO-Compress-2.061-2.el7.noarch 8/9
验证中 : perl-DBD-MySQL-4.023-5.el7.x86_64 9/9

已安装:
mariadb-server.x86_64 1:5.5.56-2.el7

作为依赖被安装:
perl-Compress-Raw-Bzip2.x86_64 0:2.061-3.el7 perl-Compress-Raw-Zlib.x86_64 1:2.061-4.el7
perl-DBD-MySQL.x86_64 0:4.023-5.el7 perl-DBI.x86_64 0:1.627-4.el7
perl-Data-Dumper.x86_64 0:2.145-3.el7 perl-IO-Compress.noarch 0:2.061-2.el7
perl-Net-Daemon.noarch 0:0.48-5.el7 perl-PlRPC.noarch 0:0.2020-14.el7

完毕!
[root@hexingxing]# systemctl start mariadb # 安装完成MariaDB,首先启动MariaDB
[root@hexingxing]# systemctl enable mariadb # 设置开机启动
[root@hexingxing]# mysql_secure_installation # 进行MariaDB的相关简单配置

NOTE: RUNNING ALL PARTS OF THIS SCRIPT IS RECOMMENDED FOR ALL MariaDB
SERVERS IN PRODUCTION USE! PLEASE READ EACH STEP CAREFULLY!

In order to log into MariaDB to secure it, we’ll need the current
password for the root user. If you’ve just installed MariaDB, and
you haven’t set the root password yet, the password will be blank,
so you should just press enter here.

Enter current password for root (enter for none): # 初次运行直接回车
OK, successfully used password, moving on…

Setting the root password ensures that nobody can log into the MariaDB
root user without the proper authorisation.

Set root password? [Y/n] y # 是否设置root用户密码,输入y并回车或直接回车
New password: # 设置root用户的密码
Re-enter new password: # 再输入一次你设置的密码
Password updated successfully!
Reloading privilege tables..
… Success!

By default, a MariaDB installation has an anonymous user, allowing anyone
to log into MariaDB without having to have a user account created for
them. This is intended only for testing, and to make the installation
go a bit smoother. You should remove them before moving into a
production environment.

Remove anonymous users? [Y/n] y # 是否删除匿名用户,回车
… Success!

Normally, root should only be allowed to connect from ‘localhost’. This
ensures that someone cannot guess at the root password from the network.

Disallow root login remotely? [Y/n] y # 是否禁止root远程登录,回车
… Success!

By default, MariaDB comes with a database named ‘test’ that anyone can
access. This is also intended only for testing, and should be removed
before moving into a production environment.

Remove test database and access to it? [Y/n] y # 是否删除test数据库,回车
– Dropping test database…
… Success!
– Removing privileges on test database…
… Success!

Reloading the privilege tables will ensure that all changes made so far
will take effect immediately.

Reload privilege tables now? [Y/n] y # 是否重新加载权限表,回车
… Success!

Cleaning up…

All done! If you’ve completed all of the above steps, your MariaDB
installation should now be secure.

Thanks for using MariaDB!
[root@hexingxing]# mysql -uroot -p # 测试登录
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 14
Server version: 5.5.56-MariaDB MariaDB Server

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the current input statement.

MariaDB [(none)]> show databases;
+——————–+
| Database |
+——————–+
| information_schema |
| mysql |
| performance_schema |
+——————–+
3 rows in set (0.00 sec)

 

据说来自斯坦福的心理学课程,根据封面广告语。

凯利·麦格尼格尔著。不知道是谁。

一共分十章。

先说意志力分为“我要做”、“我不要”和“我想要”三个部分。自控,需要分别涉及这三部分。而意志力主要来自“三思而后行”,这个对于一个冲动的人来说,真是灾难。

当你在进行决策的时候,当你需要跟自己进行斗争的时候,据说调整呼吸可以获得很好的效果。也许就是因为这位自己赢得了时间了。

克服晚睡的秘诀是:远离那些能让你晚睡的事情。

第三章揭示了一个惊人的秘密:自控力是有限量的。是会越用越少的。于是,需要锻炼功率——用更少的能量做更多的功。

第四章更是毫不留情地揭露我们的伪善:我们很容易在获得道德上的自我满足感之后,放纵自己堕落一下,以交换获得“平衡感”。你既然知道了自己的虚伪,那么无情地嘲弄这种伪善就有利于你的自控。

第五章告诉我们,我们不但善于自我麻痹,而且善于自我欺骗:我们常常会将渴望的感觉,当成幸福的感觉。多巴胺奖励的是“想要感”,比如,你想要再看翻一会儿微博,大脑分泌多巴胺刺激的让你不断产生“想看”的感觉。但实际上,多看一会儿微博会让你感到快乐吗?当你以为自己感到了“快乐”其实只是持续不断的“想看”的多巴胺的分泌。

人对甜食、美女有天生的欲望,但刺激分泌的多巴胺使人产生“想要”感的时候,并不会告诉你“想要什么”,于是你往往会从环境中随便挑一种去“要”上。这是营销伎俩。

我们渴望的东西,同时也是压力的源泉。人体会随着多巴胺的分泌,相应分泌让你感到压力的荷尔蒙,据说因此,想吃巧克力的女性“看到巧克力的时候,她们会产生吃惊的反应”。

必须区分“渴望”和“快乐”!——第五章的内容是最容易让人摸不着头脑的。这章的实质是“你欲望的并不能真正给你带来幸福”。

第六章说“恐惧会带来拖延”。压力,也会不知不觉中打扮成欲望。所以,适当减压可以减少干扰你实现目标、让你分神的欲望。因此,让自己快乐起来,有助于你坚持自己的目标。

第七章接着告诉你:让自己快乐起来,不等于及时行乐。这对于禁断欲望是一种有益的认识。但人有及时行乐的倾向,并总是乐于将禁欲的负担交给未来的自己。而“未来的自己”是一个陌生人,因为无法跟未来的自己建立共情意识。那么,认真地刻画未来的自己是否有助于现在开始“禁欲”呢?心理学研究表示有效。

第八章表示,交友很重要,朋友圈很重要。本章最后,作者做了一个实验,让陌生学生相互之间邮件通知对方自己下周要完成的事项,然后再一周之后相互提醒追问,是否已经完成。这个好像可以做成一个app。

第九章,回到“我不要”之上。表示“我不要”其实往往难以“不要”。与其强调“不要什么”,不如强调“要什么”。

第十章很短,希望大家收集自己的数据。

今天Dream提出了对投资人的不满和担忧,倒是出乎我的意料,同时也是意外之喜。

三人一番谈论之后,认识倒是空前统一起来。认清现实归根结底是件幸福的事。

当然,从我角度,能提前将销售推到一线,才是这种幸福感的根源。

虽说我们还可以审慎乐观,但多储备些冬粮还是有必要。

找到一些有意义的参考文章:

  • http://wdhdmx.iteye.com/blog/1343856
    http://www.cnblogs.com/shirui/p/5542701.html
    一样的(不知谁拷贝谁),有较清晰的示例。
  • http://blog.csdn.net/a491057947/article/details/46972825
    说了关键一句话:“如果两个字符相等,则在从此位置的左,上,左上三个位置中取出最小的值;若不等,则在从此位置的左,上,左上三个位置中取出最小的值再加上1”

目前找到的主要是编辑距离算法(LD),少数文章提及“最大子串”。看起来,这个问题对于当前体系结构的计算机来说,还是比较让人头疼的。

 

今天下午两个小时周例会。

问题依然是会议效率很低。

以前没注意过这个问题,或者说,没有从效率是否能提升的角度思考。

现在看,就是由于会议召开的方式不对。

按罗伯特议事的思想,上会的必须是一个具体的可说“是”或“否”的方案。

会议上的发言,首先应该是提前思考过的,要叫汁的东西。然后才是针对会议上新出现的议题的思考。

这样就相对不会出现漫谈似的状况,一个人发言,啰啰嗦嗦四五十分钟。

或者发言讲一半被打断,然后不知不觉扯到别的事情上去。


根据Dre上周拜访客户的反馈来看,市场情况还是有些严峻的,毕竟行业要求资质本身就是出于安全的考量。

小公司要搏大,既得靠智慧,也得擅于装孙子出让利益。

早饭的时候,苏菲谈起昨天上面来安装宽带的工人,很是夸赞了一番。

光纤拉入房间之后,原来的网线是沿着墙根绕过柜子接到路由器上的。因为柜子是后来安装的,预防倾倒就在墙上打了螺栓固定。结果走线时就无法从柜子上方放线走到柜子后面去,苏菲居然建议人家就从柜子上方走线就行了。但是小哥建议用就网线牵引把光纤从柜子后面穿过去,并且还要按我要求再还原网线布置。这一下子增加了不少工作量,关键是小哥真是不嫌麻烦。想想如果是我遇到这种情况,恐怕就听了苏菲的建议,把线爬在柜子上穿山越岭了。

苏菲说,干活的时候,不断有其他工人打电话汇报情况或者咨询问题,看着小哥还是个小领班的样子。我突然感悟道:看起来如今的劳动力市场上,只要有类似这点责任心(其实我觉得已经很了不起了),必然可以至少进入到管理层的基层了。

真是一种有意思的观察。

今天加班的时候,移动要上门装宽带,问家里是不是有人,我一想苏菲在家,就同意了,对方说马上到。

赶紧给苏菲追了电话,交待最好能保留原来的网线,因为移动这次来装的是光纤,而我现在用的服务商还是用电信号,希望能保留换的权利。

结果过了一个半小时,苏菲气呼呼地打电话过来,责怪为啥叫人上门的时候没有事前征求她的意见,结果耽误了她出门办事,“整个下午的好心情都被破坏了”。


这简直可称为“鬼畜场景”了。一方面是我总是自以为是地假设场景,另一方面是苏菲总是不能第一时间说不。性格的烙印还是教育的习性?人生悲剧十有八九是因为这种情形造成。

真正包子得空的时候,我倒是不知道该怎么招待好了。

当然聊天是主要的。然后,肉包子自然是无肉不欢的。

火火在望京美食城二层开了一个新店面,人气还不算旺呢,跟他们之前多店比起来。

泡茶不是我的强项,公司里也没啥好茶。聊起来,这些年,包子还是不怎么愿意读书。

提及这些年科技多进步,多领域的快速推进却润物无声,等听得到响到时候,已经是旱地滚雷阵阵急,一声叠一声。移动支付就是好例子。

然后说社会发展越来越依赖技术。说起比特币,讲交换到两个基本因素:确权和契约。

包子还是擅长《社会发展简史》,说起来一定要强调黄金既有交换价值也有使用价值。

然而,如果社会没有普遍到契约共识到话,黄金对你来说跟黄土没啥区别。从这个角度,比特币首先是交易规则做对支撑。做这个信息技术越来越发达的时代,货币越来越抽象已经是不可忽视的趋势,当等价交换物直接被交易记账替代当时候,中介不仅仅是被中介信息替代,甚至被中介结果替代,电子货币都显得多余。

结果今天看到一篇分析报道,说比特币交易太耗电,不如银行有效率。看到底下网友评论“银行都效率才惊人”时不禁莞尔。

今天上班晚了,到办公室的时候,他们晨会已经开完。这是好现象。

下午正在为版本对比的事情焦躁的时候,老包来了信息,说是到北京了。再细问,居然住在798的如家,离我隔着一个红绿灯、机场高速、再一个红绿灯的距离。

今天新招的外包报到了。我才想起来得给现场项目经理打电话了解情况。等打完电话才想起来,研发也需要给现场发日报。其实还不是跟项目经理的通信,而是在整个团队范围内同步信息。

不过,整个团队的能力短板还是在计划上。

老张下午到公司,讲了讲他对团队和公司目标的期望。几点都很和我口味。

1)保障研发投入。

2)建立公正的企业文化。

3)踏实创品牌。

4)第二年回本。

我趁机把团队核心成员的持股问题提了出来。老张表示可以谈。

上午继续跟Jason讨论大数据材料的准备。主要涉及三点:

  1. 技术是不是威胁
  2. 不使用技术行不行
  3. 素材

关于技术是不是威胁,结论看起来很显然。但如果切换成为“AI是不是威胁”就不是那么显然了。对于这个问题,实在有很多角度去解读,结论因此也各不相同。

首先,技术不是威胁,使用技术的人才是威胁。其次,技术是工具,使用方法错误才是威胁。最后,技术应用是潮流,重心偏离才是威胁。

大数据技术实际上是利用大量数据降低不确定性的技术。在一个越来越不确定的市场上,没有降低不确定性的技术必然处于下风。

大数据技术也是数据交换的技术,当大家都在交换中获益的时候,越是独门独户,越是容易落后。

下午把版本管理的部分收尾,总算是有了一个相对完整的设计。

昨天晚上版本管理的部分未能完成设计。上午继续。

下午被拉着讨论大数据讲稿的准备。给Jason他们普及了一下BI、AI发展小史。发现算法的部分还需要补一补课,回炉一下。

晚上陪Sun一起吃饭,聊了聊引入销售团队的事宜。


乌茶那面中午电话通知说下周需要联调接口,这事儿让我有些措手不及。

今天上午到得早,结果Lily已经在跟总助交接财务事宜了。Lily跟我说今后要我去参与演讲,搞得我很不爽。

跟Nebula聊了一下“shike”,取得了共识,大致安排了时间点。

随后我开始尝试做原型的细化设计,但进展不大,感觉还是需要一个原型工具会好些。

午饭后讨论了SD设计中的版本部分,获得了一些实质进展。但版本管理SD还得细化。

最后发现,event应用起来仍然疑虑重重。

 

参考文档:http://lansgg.blog.51cto.com/5675165/1570942。

$ cat HEAD
ref: refs/heads/master

$ cat refs/heads/master
3066f2ab7c02bd365d7fc7a8d585418847a1e2c2

$ git log –pretty=oneline
3066f2ab7c02bd365d7fc7a8d585418847a1e2c2 (HEAD -> master, origin/master, origin/HEAD) Merge branch ‘v2.0’ into ‘master’
6e45a4af309b4b098282ff86ac29d5e103ea8bc1 (origin/v2.0) 在Event WAKE中增加了scheduleId属性,用户记录任务唤醒隶属于哪一个Schedule。
a8943452348118125f4f664e7fd0a4bed944108e Merge branch ‘v2.0’ of 10.1.194.23:Doc/ontology into v2.0
be7e5db1b08770486a203b9ae07829149b0a651e # 修改WebDataSource语义定义。
bfa13920a98e96e161cce4255ecc4ecd21002649 # 修改WebDataSource语义定义。
83d046fcd5f59c2bddc3b4d7c9f7717d886941fb Merge branch ‘v1.0’ into ‘master’
fd8b2881f2262e4c384c455248b3610bc747a5c2 (origin/v1.0) # 添加以下Node
ea5a81134eda6b452ae065508060d244cef4577f 修改District title属性错误。 修改Landmark lat属性title错误。 补充Landmark属性缺失的title。
b385bbb98ffca7df5ebacea46834f9df55b3a9fb 删除企业定义中重复品牌属性定义。
8b0e7d4f97e6fc9b7f354e1eafa7141874ba27b9 添加Word的name和pos属性的title描述。
6dc6c29bc785821f742f51c9cdb80e17bf846113 修改默认属性置信度和来源的title
0f9621346ef566651f5d24b263d7bafbb741e3cd 添加ProductName,以及和TextContent关系。
[…]

$ git cat-file -p 3066f2ab7c02bd365d7fc7a8d585418847a1e2c2
tree b554cb339fc61cafe7e1ca6aba6fadec00d97ba5
parent 83d046fcd5f59c2bddc3b4d7c9f7717d886941fb
parent 6e45a4af309b4b098282ff86ac29d5e103ea8bc1
author 赵子龙 <zhaozl@shuguo.com> 1477275171 -0400
committer 赵子龙 <zhaozl@shuguo.com> 1477275171 -0400

$ git rev-parse HEAD
3066f2ab7c02bd365d7fc7a8d585418847a1e2c2

$ git rev-parse HEAD~2
ea5a81134eda6b452ae065508060d244cef4577f

$ git cat-file -p 3066f #当前commit下的内容
tree b554cb339fc61cafe7e1ca6aba6fadec00d97ba5
parent 83d046fcd5f59c2bddc3b4d7c9f7717d886941fb
parent 6e45a4af309b4b098282ff86ac29d5e103ea8bc1
author 赵子龙 <zhaozl@shuguo.com> 1477275171 -0400
committer 赵子龙 <zhaozl@shuguo.com> 1477275171 -0400

$ git cat-file -p b554cb339fc6 #当前commit下的tree的内容
100644 blob 52ba2b3533391f51cc4650e1f136f6839e2d9691 .gitignore
040000 tree 3ab67d2edd5b40274dc6d6435e321497dbeda437 bin
040000 tree 225fd4c34e67f393fa512796de2d24d78d4a5cdc doc
040000 tree 1c5f9a90b24fb1b24cb0db8306b394805e5043e6 node_modules
100644 blob 5a7a5208602d0033fc5d2400d1051ed4358c4abf package.json
100644 blob def05e017fcc12384566e104a9578997a0f7d25e pom.xml
100644 blob 05b3becbb4c9887849afbe764e59f78e230b1198 readme.md
040000 tree 6eb8abe3c8c28e8bbd8b88e922e9436e639f1750 src

$ git show 5a7a5208602 #显示package.json的内容

根据这篇文章

index工作在暂存区。记录文件的时间戳、文件长度等属性,形成包含文件索引的目录树。

那么当一个文件被修改过之后,它的属性时间戳、文件长度就有可能会发生改变。这样一来,当我们再输入 git status 的时候,index这棵大树就会将目录树中所有文件的时间戳和文件长度和工作区的进行比较,如果发现不一样,那么就能判定不一样的文件经过了修改。

于是我们可以看到三种对象:commit、tree、blob之间的关系如下:


粗略一看,可以大致感觉出blob类似于文件,而tree类似于文件夹,而commit则是囊括这一大堆东西的一个对象。没错,其实从广义上来说就是这样的。
如果我们在工作区新增一个文件,然后通过 git add 加入到暂存区,那么git同样地会根据这个文件通过SHA-1算法来计算出属于该文件的一个HASH值。

这样,git利用hash在文件系统中形成一个分层目录以便利用文件系统的目录快速检索blob文件。

然后,git利用tree将实际项目的文件目录结构与上述hash后blob映射起来。每个tree对应一个实际项目的文件目录。也就是说,每个tree节点就是一个文件目录。

最后,commit就是一份描述文档,说明一次提交的内容以及相关说明,内容样例如下:

tree b554cb339fc61cafe7e1ca6aba6fadec00d97ba5
parent 83d046fcd5f59c2bddc3b4d7c9f7717d886941fb
parent 6e45a4af309b4b098282ff86ac29d5e103ea8bc1
author 赵子龙 <zhaozl@shuguo.com> 1477275171 -0400
committer 赵子龙 <zhaozl@shuguo.com> 1477275171 -0400
[…]

于是,基于所有的commit文件,记录了一颗版本衍变树。每个版本的文件/目录树由tree记录,而文件和目录以及commit文件的压缩存储统一由blob及其基于hash的检索结构处理。

而tree总是记录一个完整的commit,包括那些本次未变更的blob。参考这篇文章,index文件则对应着stage区”staging area”。

tag则是对某个特定tree的标记,这个标记可被删除时是branch,不可删除时是一个发布版本。

这里看到的文章,感觉将底层数据模型说得还比较多:

1.对象模型(Object Model)

hg是采用增量式存储的版本控制系统,它保存相邻版本间的差异,通过在基础版本之上叠加差别的方式记录版本的更新,其组织方式自然采用链表。这点和subversion一致,数据库版本控制工具dbdeploy也采用相同原理。

hg中的基本对象有三种:file、manifest 和changeset

  • changeset可以理解为版本的代名词了,它记录了该版本的信息,changeset间的采用链式索引,由一个根开始;
  • 每一个changeset持有对应版本的manifest,这是一个记录repo内当前工程版本下的各文件版本信息的列表;
  • 每个file对应的Revlog 文件才是真正存储各版本以及其数据节点的列表。

git并非采用增量式存储,而是为每个版本创建一个快照,最重要的组织结果是树。

基本对象有三种,自底向上为:blob、tree和commit(还有个tag, 和hg的bookmark类似,略了 )

  • blob存储的是repo中某文件的内容,单纯的二进制方式,不存储包括文件名在内的其他东西。它是脱离于版本之外的存储结构,通过对文件数据的hash值比较可快速区分两个blob,不同版本、或不同目录下、或不同名称但内容相同的文件共有相同的blob对象;
  • tree存储了所有directory和file的组织结构,对directory存为子树,对file保存其对应blob对象的hash值;
  • commit也是版本的标志,它持有tree的root节点地址,相邻commit之间也是链接在一起的,以方面找到上一个版本。

2. 工作目录与专用目录(working dir and Git/Hg dir)

两种版本控制工具都将代码checkout到工作目录下,工作目录中保存的是项目当前branch的当前版本;同时在本地repo的根目录(也是工作目录)下为各自系统建立一个专用的目录(.hg , .git), 存储版本历史、对象与索引和配置文件等。

不同之处在于建立codebase时,这里首先要提到bare repositories的概念。

# Why bare?

一个bare repo与普通repo的区别是没有项目文件的working copy,即repo根目录下只有专用目录,而没有任何其他代码文件和文件夹;这是为了响应作为codebase应当遵循的“Only store, never update from revisions(只存储版本,不更新到实际代码文件)”原则。

hg管理的repo天生就能做codebase使用,无论是否是bare的,这点是由其分布式版本控制系统的本质决定的,它可以随时把当前的repo通过自带的http server发布代码,特别适合分布式开源项目的代码分享。

git也是分布式代码版本管理工具,不过它对作为codebase的repo做了严格的bare要求。可以看到的是许多人在初学git时不了解这一点,抱怨自己做spike时不知如何提交代码到在本机上的codebase。这里顺手写下两个tips:

* 初始建立一个bare repo

$ git init –bare

* 如果已有一个repo了,使用下面的方法将其转化为bare的

$ git config –bool core.bare true   , 之后可删除除了repo根目录.git文件夹之外的所有文件,即只保留专用目录

3. 分支与合并(branch and merge)

git中是有同一个repo上不同branch的概念,而hg没有。就是说,git在切换到别的branch上时,仍然是在原来的repo中,工作目录下的代码也会相应地切换到某个版本上;而hg上新建branch 则意味着有了另一个repo,不能算做轻量级的分支(lightweight branch)。

hg中是以heads的概念来维护不同开发者checkout的代码的,它不像SVN这样的集中式版本控制,不需要回归到某一根主线上来(当然常常我们需要这样用,方便持续集成),所以向某个codebase提交时需要先与该branch上的head来merge,结果合并为一个新的共有的head(这显然需要一次提交),此时两条branch交汇到一处。

git中可以在同一repo下,实现在指定branch上独立提交和在不同branch间merge。提交和更新是灵活和易控制的。

另外,hg中鼓励以changeset为单位进行merge后提交,即先将本地修改做本地提交,之后采用mercurial queue或fetch的方式合并后提交到codebase。其原理是head之间的合并。

git中鼓励在未形成本地commit时更新代码并做merge,之后将本地提交和向codebase提交连起来做。因为本地commit之后做更新和合并,并不是git对象模型所擅长的,被迫merge时容易将被引入“no branch”的临时branch状态。这种状态上也是可以进行开发的,但风险是没有正规的branch来记录版本。这里又有一个tip。

# ‘no branch’ problem

* 从“no branch”状态转回正常branch上, 比如master

1)在“no branch”状态上完成与代码库的同步,即保证没有重要的本地修改和本地提交残留;

2)$ git checkout master     ,直接转到master上,这时对no branch的索引就丢失了,该状态不复存在;

3)$ git log    ,检查master branch上的log,找到是否有本地修改/提交残留(通常是有的,因为是在做merge时出的问题);

4)$ git reset –hard HEAD~3,    放弃已有的本地提交(假设是3个,如果是两个可用HEADE^^),–hard是删除指针及内容;

5)在没有本地修改和提交的基础上,就可放心地同步到master上最新的版本了,你知道怎么做这步。

其他

诸如git的unstaged area,mercurial queue以及两个工具的应用模式,都不在此介绍了。

参考

http://mercurial.selenic.com/wiki/GitConcepts

《Git Community Book》

这篇文章则重点介绍git。提及数据结构的重要性:

Git 数据结构设计的非常精良,据说在之后十年的开发中,feature 扩展了无数,基础数据结构却很少变动。体会一下 Linus 的一段话:

Git 的设计其实非常的简单,它的数据结构很稳定,并且有丰富的文档描述。事实上,我非常的赞同应该围绕我们的数据结构来设计代码,而不是依据其它的,我认为这也是 Git 之所以成功的原因之一[…]依我的观点,好程序员和烂程序员之间的差别就在于他们认为是代码更重要还是数据结构更重要。

比较全面地介绍git底层:

OutOfMemory.CN技术专栏-> wiki-> 独孤九剑 – git的设计思想揭秘

独孤九剑讲究料敌先机,无招胜有招。在程序世界里,需要根据不同的需求不断的迭代。系统不能像剑法一样随手变更,往往需要花费无数个人月「最近体会到可以把变化做成接口,留给用户,来应对一部分需求变更」。 程序=算法+数据结构 , 很少有像 TeX 那样,在算法和数据结构两方面都趋近完美,Donald 独自完成了 99.99%,甚至连 bug 数,都少到了惊人的地步。我认为程序设计最重要的是数据结构,深刻理解数据结构,设计最合适的数据结构,以不变应万变,才能抓住需求的本质,解决用户的痛点,做到在需求变化或者转型时,改变最小。

总决

以不变应万变

烂程序员关心的是代码。好程序员关心的是数据结构和它们之间的关系。

数据结构

Git 数据结构设计的非常精良,据说在之后十年的开发中,feature 扩展了无数,基础数据结构却很少变动。体会一下 Linus 的一段话:

Git 的设计其实非常的简单,它的数据结构很稳定,并且有丰富的文档描述。事实上,我非常的赞同应该围绕我们的数据结构来设计代码,而不是依据其它的,我认为这也是 Git 之所以成功的原因之一[…]依我的观点,好程序员和烂程序员之间的差别就在于他们认为是代码更重要还是数据结构更重要。

心里痒痒的,就让我们来一窥 Git 的奥秘吧。

Git的设计思想

  • 直接记录快照,而非差异比较

Git 不存储文件差异,把数据看作是对小型文件系统的一组快照。每次你提交更新,或在 Git 中保存项目状态时,它主要对当时的全部文件制作一个快照并保存这个快照的索引。 为了高效,如果文件没有修改,Git 不再重新存储该文件,而是只保留一个链接指向之前存储的文件。下图中如果与前一个版本相比文件有改变,则存储新文件(快照)到下一个版本中。如果没有改变,则只存储之前文件的索引,如图虚线框所示。

git-snapshots

  • 近乎所有操作都是本地执行

在 Git 中的绝大多数操作都只需要访问本地文件和资源,一般不需要来自网络上其它计算机的信息。你能愉快地提交,直到有网络连接时再上传。

  • Git 保证完整性

Git 中所有数据在存储前都计算校验和(使用 SHA-1 散列),然后以校验和来引用。 这意味着不可能在 Git 不知情时更改任何文件内容或目录内容。 这个功能建构在 Git 底层,是构成 Git 哲学不可或缺的部分。 若你在传送过程中丢失信息或损坏文件,Git 就能发现。

  • Git 一般只添加数据

你执行的 Git 操作,几乎只往 Git 数据库中增加数据。 很难让 Git 执行任何不可逆操作,或者让它以任何方式清除数据。

  • Git 的三种状态

Git 有三种状态,你的文件可能处于其中之一:已提交(committed)、已修改(modified)和已暂存(staged)。 已提交表示数据已经安全的保存在本地数据库中。 已修改表示修改了文件,但还没保存到数据库中。 已暂存表示对一个已修改文件的当前版本做了标记,使之包含在下次提交的快照中。

由此引入 Git 项目的三个工作区域的概念:Git 仓库、工作目录以及暂存区域。

git-work-area

基本的 Git 工作流程如下:

  1. 在工作目录中修改文件。
  2. 暂存文件,将文件的快照放入暂存区域。
  3. 提交更新,找到暂存区域的文件,将快照永久性存储到 Git 仓库目录。

Git 文件的生命周期

工作目录下的每一个文件都不外乎这两种状态:已跟踪或未跟踪。 已跟踪的文件是指那些被纳入了版本控制的文件,在上一次快照中有它们的记录,在工作一段时间后,它们的状态可能处于未修改,已修改或已放入暂存区。 工作目录中除已跟踪文件以外的所有其它文件都属于未跟踪文件,它们既不存在于上次快照的记录中,也没有放入暂存区。 初次克隆某个仓库的时候,工作目录中的所有文件都属于已跟踪文件,并处于未修改状态。

编辑过某些文件之后,由于自上次提交后你对它们做了修改,Git 将它们标记为已修改文件。 我们逐步将这些修改过的文件放入暂存区,然后提交所有暂存了的修改,如此反复。所以使用 Git 时文件的生命周期如下:

git-lifecycle

Git 保存数据的方式

为了说的更加形象,我们假设现在有一个工作目录,里面包含了三个将要被暂存和提交的文件。 暂存操作会为每一个文件计算校验和(使用 SHA-1 哈希算法),然后会把当前版本的文件快照保存到 Git 仓库中(Git 使用 blob 对象来保存它们),最终将校验和加入到暂存区域等待提交:

$ git add README test.rb LICENSE
$ git commit -m 'initial commit of my project'

当使用 git commit 进行提交操作时,Git 会先计算每一个子目录(本例中只有项目根目录)的校验和,然后在 Git 仓库中这些校验和保存为树对象。 随后,Git 便会创建一个提交对象,它除了包含上面提到的那些信息外,还包含指向这个树对象(项目根目录)的指针。如此一来,Git 就可以在需要的时候重现此次保存的快照。

现在,Git 仓库中有五个对象:三个 blob 对象(保存着文件快照)、一个树对象(记录着目录结构和 blob 对象索引)以及一个提交对象(包含着指向前述树对象的指针和所有提交信息)。

commit-and-tree

做些修改后再次提交,那么这次产生的提交对象会包含一个指向上次提交对象(父对象)的指针。

commits-and-parents

引用

  1. ProGit2

今天上班在电梯里碰到之前给我们做装修的设计师,一打眼第一句话就说我胖了。寒暄了一会儿,临下电梯还补刀:嗨,真的该减肥了。

这话飘过的同时,感觉身体里有什么东西挣脱了。


周末加班做设计讨论会,当时激烈争论的问题,今天终于慢慢捋清楚。

我希望系统有一个存储驱动层,完成SD到存储介质的转换。这个存储驱动层首先将SD元数据映射为存储介质的元数据,然后基于这个映射形成驱动程序,最后使用这个驱动完成两边数据的格式转换,实现存取操作。

而同事认为“SD-介质元数据”的映射较为复杂,想改造SD元数据使其可以跟RDB元数据一一映射,从而使“基于这个映射形成驱动程序”尽可能简单。

而我认为在我们对介质元数据已经使用SD完成建模的情况下,实际上等同于完成了“SD元数据映射为存储介质的元数据”的过程,只是没有显性写出映射规则。所以其实驱动程序呼之欲出。

争论了几天,始终没有想清楚脉络,找不到症结所在。

一直存在关掉鼠标之后就无法再次连接的问题。前几次都是一番开关或者用缆线连接插拔,撞运气连接上了。

今天忍无可忍,上网查到这篇文章提到:

检查是否有信号干扰

  • 以 2.4GHz 运行的无线网络可能产生干扰。如果怀疑有干扰,请将无绳电话基座、微波炉和其他 2.4GHz 电气设备从 Mac 附近移开。

然后果断关掉wifi,点击鼠标激活,顺利连接!

以后macbook出现鼠标无法连接问题就有思路了。

新来同事今天第一天上班,发现了一趟公车可以直达公司楼下,很高兴。

中午吃了越南粉。

到了下午快下班时,连平时吃得最少的女同事都饿了。

CWM学习有些进展,但对于建模语言的定位还不是很熟悉,设计时总是失焦。


今天苏菲出现感冒症状,貌似季节性的调节失灵。

今天晚上几个同事就被迫再次出发去项目所在地。现场bug太多,项目经理顶不住了。


中午老Niang去中铁买的外卖,我发现他们吃的米饭🍚太挫了,跟苏菲建议下次焖好了带过去。

完事儿又去姐夫家里瞧绿植的情况,貌似有一盆已经救不过来了。

回家又是很困,很经济地睡了一会儿。

然后发现可以下美剧《mindhunter心理神探》看。

特别喜欢其中对话的话锋。

 

早上醒来得早,想了想决定尽快到公司。结果我八点二十分到公司的时候,居然大家都来了。

于是我借机说了去麦当劳吃早饭时想到的问题:当前我们纠结的困难实际上跟我们的战略重点没有关系,我们应该首先在战略重点问题上寻求突破,也就是要解决基于元数据进行数据处理的问题。

稍微一点争执讨论之后,大家同意我的判断。正当我得意地在窗边发呆的时候,董事长到公司,招呼我的时候我都没听见。才想起来,今天董事长要带合作伙伴一起在公司开会。让我有些心浮气躁。

快到中午的时候,我们才开始讨论元数据部分的设计问题。大家围绕在我的座位边上,我给大家讲对元数据部分的设想。又是边争论边推进论述。

还是需要及时总结一下:通过这番讨论,说明我对元数据的设想的阐释在之前的设计文档中表达非常有限。很多想法只是留存在我的脑子里,未能在文档中以形象的方式向大家传达。

我之前想象中的初始化场景,缺乏具象化的说明。所以,从设计的角度、需求的角度,都需要给出一个具体原型。这个原型的形成,可以是从每个界面一句话开始,逐步推进到给出了主要的交互元素。

午饭之后,还在星巴克买咖啡,同事就喊我回去开会,给客户介绍我们的产品。交流完之后,开始沉心学习CWM,还没等我理顺思路,我的第一客户就按约来做阶段交互。

现在的获客不理想,主要是大家都关注销售,我们的数据内容跟营销密切性不大,大家的采购热情就明显受影响。

一早到公司之后,晨会完毕,大家进会议室讨论昨天的遗留问题:哪些公共组件。讨论过程明确了一个观点:

要将UGC的使用行为引入到行业软件的使用中,使得业务功能可以基于内部利益相关方的主动互动实现。

但这个想法看上去有些过于激进,同事强烈反对。不过我坚持认为,只要界面组织方式得当合理,至少在某些特定领域中是可以达成的。接近中午吃饭,我终于明白:至少单纯的对数据增删改查是可以采用UGC的方式的。

下午开始讨论流程的设计问题。讨论的后半段,我发现UXDF对于BPM类的切面角度是不同的,导致寻常的BPM定义过程用UXDF来表达可能很难理解,尤其是我们将参与人和活动都放置在event上时。

搞到快八点还是没到达终点。

讨论了一上午的界面设计。终于搞清楚一件事:我对notion的兴趣来自于在应用软件中引入UGC行为。

其实这是一个有趣的课题点:行业软件是否可以像UGC那样发生良性的自组织效果呢?

值得认真做实验。


周一形成page-flow。

周二形成component design。

周三形成restful接口。

目前为止component这块的讨论多花了一天时间,这跟我前期思考无法深入有关系。而不能深入的阻力点,从讨论过程看,是因为我回避了深入思考,右侧button的具体内容。

看来从一个新模型的可行性来说,给出一个高保真的模型还真是不可回避的内含科学规律的方法路径。


下午去了解了广电项目的相关情况,发现组织上比我想象的更为松散,交互界面研发这块的话更需要能专注投入的全日制团队。


今天19大召开。群里有领导发言的脑图总结。浏览一下,总体感觉并没有新东西。其实每次我看这些人的发言都是这种感觉。还是没有掌握他们的语言模式。

昨晚出差同事的飞机落地时,我好像已经进入迷糊的状态了,所以没看到微信回复。

上午才发现有些遗留问题没有控制住:

  1. 未要求出差小同事提前进行部署的演练,
  2. 也就没有对部署版本再进行测试!
  3. 之前要求带测试数据,临行前一天也未进行检查。

尤其2,显得团队水平太水了。

上午晨会才知道,昨天接孩子早退的同事晚上并没能补上进度。所以上午补课,下午才开始讨论今日功课。

但是时间控制不好,大家经常说着说着,焦点就变了。如果说是我在组织会议,那么这是我没有控制好重点。反过来,说明大家对于每个内容到底是什么主题,其实也没有清晰共识。所以,这是方法初期大家生涩的表现。

因此不知不觉就争论到七点半。


NotionDocument需要从两个层面拆开来定义:一是用户数据的簇集,一是展示样式。

从簇集的角度,就是将用户数据从数据库中提取出来聚集在一起的手段。我个人认为这是NotionDocument的本质。至于数据展示成什么样式,实际上是同簇数据的样式决定的。

上午到公司的时候大概是九点十分,同事已经都到了。

将本周的计划邮件发出之后,召集大家开晨会。讨论了LC出发去项目现场的若干事宜之后,决定还是给项目经理写封邮件,把情况都交待清楚。然后写着写着就发现,还得把过程中用户侧提交的文档也一起交接。

按说项目管理最是需要规范化,不仅过程是有框架的,环节中有哪项内容也是有框架的,甚至每种内容的合规度也是有框架的。新来的项目经理没有在任何一个维度上按某种规格来要求交接内容,可见经验不足。

然后利用一点零碎时间打算记录昨天发生的事情,结果发现昨天上午做了哪些事情居然毫无印象。打电话问苏菲才回想起来。可见休息天我自己是全无线索的。

饭后就开始讨论页面流和交互方面的设计思路。等我们讨论完,大概五点二十,LC也出发去机场。问为啥这么早去,说是早点到机场吃顿饭。小姑娘胃口好不是坏事。

早起,也许是昨天睡多了,苏菲罕见地看着我的脸色说水润发光。

早餐就剩下两片面包,吃完了决定去完成浇花大业。

进了褐石发现植物们都快渴死了,发现帮助植物恢复生机的事情还是很愉快的。

 

商议去哪里吃饭,苏菲照顾我念叨“直面东京”两天了,于是进了这家店。本打算在体验一次骨汤拉面的魅力的,结果实在有些饿得发慌,这阵子控制碳水化合物摄入量,胃部很久没有撑的感觉了,于是点了一碗牛肉饭。

再次证实:其实我的饮食快感至少有一半来自于胃部。

然后抓紧时间再去奥森跑跑,结果进了北门看到一堆游览自行车,灵机一动鼓动苏菲租一辆骑。然后骑过河之后,逆时针方向顺着道骑,然后快到非洲女神雕像之前的大门处,其实是禁止游览车通行。我们趁乱飞快地骑了进去,也算是经历了一次标榜的违法行动。

然后跟同事越好讨论后续设计方案,畅谈到快六点。

晚上苏菲建议喝粥。逛商城,买了件Lee衬衫。

早上起床的时候苏菲就念叨着要去奥森走走,饭后看看天气阴翳,但是确实好久没有活动,还是下了决心去活动活动。俩人走了一圈,两点半多了才出来。

然后照顾苏菲的情绪,跑去吃那家湖南粉。接着逛超市买早餐,结果变成把晚餐也买了,于是本着女孩富养的原则,买了鲜活的所谓“美国基围虾”,一百四十八一斤。一共20尾,打算分两顿做。

回家还是没顶住困意,看见苏菲歪在沙发上眯着了,也躺床上睡了一觉,结果连本来打算给老妈打视频电话的事儿都忘了。

晚上做晚饭的时候,苏菲问我做多少,我又拿不定主意,一来打开塑料袋发现居然多数虾还活着,有的还有力气蹦跶,新鲜的不吃要吃冻死的?

苏菲显然也是馋了,于是就一锅白水烫了。

大快朵颐。