Fly Alone

Share
原来电影里的都是真的

每年在拉斯维加斯都有一个展销会。我父亲以前是很少去的。自从我来美国了之后,这个展销会却成了为数不多的碰面机会。所以经常是今年我去拉斯维加斯,明年我父亲来纽约。

今年又轮到我去维加斯了。因为之前那次去维加斯没看成什么好的秀。于是这次我提前订了太阳马戏团的KÁ,订好了宾馆租好了车,准备当一次尽职地陪+翻译。

奈何从纽约直飞维加斯的飞机不多,并且为了在他们落地之前我先料理好一切事宜,于是我订了早上6点的机票。如果一切顺利,我会在上午9点左右落在Vegas,提了车子,等他们落地先接他们去吃顿好的,然后去宾馆休息下,晚上再去看个秀。完美。

于是我早上3:30左右起床,洗漱,然后4点多打车去了机场。强忍着困意领了登机牌,过了安检,在候机厅等了半个小时,等到5点多的时候开始有人排队登机了。这里要吐槽一下纽瓦克机场:我的登机牌上写的是Gate 41,然后 1.Gate 41那里没有显示器显示登机航班,2. 他根本没有Gate 41,只有41A和41B,而且是紧挨着的,两边的队伍都连在一起了。当时考虑到这个时间起飞的飞机应该就是我要乘的航班,于是强忍着困意站起来排队。到了我的时候,机组扫了我的登机牌,并挥手让我进去。于是我就进了飞往迈阿密的航班。

本来到这里依然是可以发现我做错了航班的,但是一来我太困了,上飞机就开始睡;二来我本该坐的航班的座位在去往迈阿密的航班上竟然是空的。于是我上机倒头就睡,全程都没觉得有问题。甚至到飞机快落地的时候听机组说local time是9:02 —— 我“应该”坐的那班航班是9:10落地。当时我还庆幸居然提前了8分钟落地。

落地之后我就懵了——怎么是welcome to Florida? 然后急忙忙的开始联系重新订票,联系宾馆late checkin,最担心的是我那语言不通的老父亲要在Vegas等我8个小时(后来远程协助打到了车,入住了宾馆,KA的票也退掉了)。在餐厅的时候还和服务生卖了个惨,她听闻我要在机场等8个小时,送了我一瓶苏打水(同样的招数在想升舱的时候被识破了,并没有任何同情价/折扣)。

最后统计一下,整个损失是:

  • 吃了两顿机场餐(尽管有21块钱的代金券,依然自己掏了20块)
  • 比预期晚了11个小时到Vegas
  • KA秀没看成

整个事件中学到的教训是:

  • 再困也要问一嘴。。。。工作人员都太不靠谱
  • 不要买早上9点以前的机票
  • 随身带switch是我做的最正确的决定。

另:坐上飞往Vegas的航班,点开娱乐系统看电影推荐,前三个里面有两部是home alone。sigh.

Read more

低绩效同事,先别急着下结论

低绩效同事,先别急着下结论

团队里最难处理的,往往不是最差的同事,而是那些卡在board line上,挤挤能出活、但不挤就磨洋工的low performer 同事。 这类 low performer 一出现,很多Manager的第一反应就是:ownership 不行。问题是,这句话太空了,空到几乎没法行动。 我更喜欢用一个简单的框架看这件事:先判断原因,再调整支持,接着设观察期,最后做去留决定。 先判断:到底是哪一类问题 low performance 不等于 low ability。常见情况其实不一样: * 不会做:能力还没到,拆问题、推进、沟通都卡住。 * 不想做:知道怎么做,但投入不够。 * 做错方向:很努力,但目标理解偏了。 * 岗位不匹配:人不差,只是不适合这个角色。 比如: * 一个同事总是晚交,但每次都能把问题讲清楚,可能是任务切太大了。 * 一个同事总返工,

By andy

Vibe coding 之踩坑记

Vibe coding 对于程序员的技能要求反而比之前高了 先讲一个故事。 我这几天突然被隔壁组叫去,帮他们解决一个支付系统的问题。 简单来说,我们的客户分成机构和下属的医疗场所。一个机构下面可能有多个场所,然后机构可以统一管理下属场所的账单,支付等等。这样就需要我们能在我们的支付系统里面建立一个关系树,让父结点能看到子节点的账单,并支付。 问题就出在这个关系树上。因为我们之前用过一个另外的支付系统,所以有一部分老客户是从之前的系统迁移过来的。 这个老系统给每个客户创建了一个独特的id,但是这个id 和我们内部使用的id 并不一致,所以我们需要自己把客户的id 和他们的支付账户连接起来。然而: * 新的支付系统只支持固定的一些属性进行搜索。所以之前做这个项目的工程师A耍了个小聪明,用客户的last-name 属性存储了我们的id * 第一个雷:用户的last-name是可以由用户自行修改的。如果他们修改了,我们的对应关系就乱套了。 * 但是这个id A存错了,应该存储机构的id,A存成了下属场所的

By andy

关于flashblocks

争取整个短文系列,迎合短视频的潮流。 base前段时间整了个活,提出了一个新的概念叫flashblocks。 在有flashblocks之前,每个区块的状态是要么这个区块还不存在,没法拿到区块的任何状态和信息;要么就是这个区块已经存在了,它的状态是不可变的,拿到就是最终区块。base链每2秒产生一个新的区块,即任何的交易需要2秒钟才能确认。 如下图,区块A生成之后,2秒内用户只能看到区块A,直到区块B生成。 flashblocks呢,它允许用户提前获取正在打包的区块的状态。正在打包的区块每200ms更新一次状态,直到10次更新之后,正在打包的区块变成一个完整的区块。 如下图,区块A打包200ms后,用户可以立刻看到区块B的状态0. 再200ms后,可以看到区块B的状态1,直到区块B的状态9,然后区块B稳定,开始生成区块C的状态1。 flashblocks的好处是什么呢?它可以在一个区块完全打包好之前,让用户提前知道自己的交易是否有被打包进当前的区块,加速交易状态的确认。 缺点又有哪些呢? 首先这个确认属于预确认(preconfirmation), 这个预确认还没有状态更新

By andy