Category: Reading Notes

[Notes] Why Amazon DynamoDB isn’t for everyone

WeiranLeave a comment

https://read.acloud.guru/why-amazon-dynamodb-isnt-for-everyone-and-how-to-decide-when-it-s-for-you-aefc52ea9476

So when you combine inexperienced devs, the lack of a clear plan for how to model a dataset in DynamoDB, and a managed database service that makes it really easy to ingest a lot of unstructured data — you can end up with a solution that spirals out of control even at a small scale.

Quick and dirty prototypes done with try and error models would be the best use case for DynamoDB. At the same time, building a real product directly on top of a working prototype is a dangerous approach and set up for failure.

A relational database will do most anything you need at small scale. It might take a little longer to set up initially than DynamoDB, but the well-established conventions of a SQL implementation can protect you from a lot of wasted time down the road.

The initial time it took can take you way further than you would expect if you head down the RD SQL way.

So if your application is using too many RCUs on a single key, you either need to over-provision all the other partitions (expensive), generate a ton of “Throughput Exceeded” errors (not ideal), or figure out how to decrease access to that key.

One takeaway here is that DynamoDB isn’t necessarily suited to datasets that have a mix of hot and cold records.

End of the date, if it is a good use case for DynamoDB, it should also be a good use case for Azure Table, which in my opinion, even much simpler and much more scalable. And Azure Table is truly performance-provision-free.

Business value trumps architectural idealism every time.

That kind of decision making can tell a mature architect from a mediocre one, especially for the line of business software development.

This is why Lynn Langit has more or less abandoned NoSQL as a solution for small and medium-size businesses.

It depends on the balance. Breaking schema changes in SQL is a huge pain. Plus if CI/CD, no-downtime deployment is a must-have, involving changes to the index, for a relatively large database, SQL will take a bigger hit. But anyway, to do all the above, even NoSQL won’t be trivial.

[Notes] 万维钢解读：《成功公式》

WeiranLeave a comment

所以说“赢了起跑线”这句话的关键词是*赢*。你光是起步早、比如说让孩子很小就去上这个班那个班，是不行的 —— 你得让他*赢*才行。只有战胜对手脱颖而出，才能给他带来真正的自信，才能向社会证明他的“可被奖励性”。

以前焦点都是『起跑线』，争论人生是长跑不是短跑。其实注意力应该是这个『赢』字。

我以前听说过一个说法：要看一件事能不能办成，在你调兵遣将把这个团队建立起来的那一刻，就已经决定了70%。

暗暗迎合了VC只看团队的说法，什么产品，什么技术都是其次。

有句话叫“艄公多了打翻船”，说公司用人不能只招“牛人”。

要想既有传统又有创新，团队成员必须既有强联系又有弱联系。你得有老人，有新人，还得有外人。

这说法跟现在的市场行为不符，现在的公司就只想招『牛人』和『新人』。当然，哪里真的有这么多牛人，只要招多了，自然而然不知不觉能与不能都好，反正就做到了『不只招牛人』。

接受了这个定律，每个人都应该大度一点。如果你是新手，别在乎眼前的得失，你想要的不是一两个功劳，而是自己的系统！

现在很多人爱说“拥抱不确定性” —— 请注意，说我不怕 r 值的不确定性，对各种想法持开放态度，这可不叫“拥抱”不确定性。你得主动出击，毫不懈怠地一个项目一个项目做下去，没有新 r 值就难受，这才叫拥抱。

两个字『深耕』。

[Notes] Calculating Derived State in JavaScript Using Selectors

WeiranLeave a comment

https://nick.scialli.me/calculating-derived-state-in-javascript-using-selectors/

We can use selectors to solve this issue. Selectors are functions that take state as a property and return the derived state value. Let’s see if we can create a selector to replace our allowedIn property.

Our decision is not just based on our state object anymore, but is based on the result of another selector as well. This is where we start using higher order functions to compose selectors from other selectors. 

Many selector libraries (e.g., Reselect for Redux) include additional functionality to memoize selector results.

Great examples that explain why we need Selectors and how to use them for calculating derived State (like a computed property.)

[Notes] How Hasura saved us $50,000

WeiranLeave a comment
View at Medium.com
https://medium.com/cresta-engineering/how-hasura-saved-us-50-000-7cfe8e7909e9

front-end stack of React, TypeScript, and Apollo.

React gets more tractions. TypeScript is still not out-of-the-box supported. At the same time, more and more start-ups using TypeScript with React together. May it worth the effort to add that extra layer? So that the project is more maintainable?

Hasura markets their product as a “GraphQL-out-of-the-box.” It’s a standalone server that sits between your database & client. This differentiates Hasura from other offerings (like Prisma), and puts it closer in spirit to projects like PostGraphile.

More like a self-hosted managed BaaS.

But this isn’t how Hasura works. Instead, every GraphQL operation you send to the server is transpiled to raw SQL.

Sounds pretty straightforward on paper. That is no “magic.” But just looking at the generated SQL, may be useful for performance tuning troubleshooting, but not sure how much that will help to migrate to other vendors when decided Hasura is not the best option.

simply state the data requirements of your UI, and let a library handle everything else.

Very nice to have!

Besides remote schemas (a feature also available in a few GraphQL solutions), Hasura offers a clever feature: create any view or stored procedure, and Hasura can automatically generate GraphQL operations. Subjectively, complex data transforms are far easier to write and maintain in SQL than they are in JavaScript or TypeScript. Being able to go from creating the view to querying it in the client in mere seconds feels feels almost like cheating.

Not quite sure what kind of “data transforms” the author refers to but doing anything in SP never felt to be enjoyable. SQL is not a language to implement business logic. Creating views may still seem fine to me.

Now, that same button is simply a matter of updating the client, clicking a few things in the Hasura UI, then testing & deploying. We’ve cut the amount of server code we have to maintain by 2/3rds, allowing us to spend that time building more cool stuff for our users.

For CRUD liked operations, that seems very handy. Not sure about other buttons with more complex logic behind.

WWDC 2019

WeiranLeave a comment

SwiftUI

终于可以彻底离开ObjectiveC。看演示的例子应该简化的不少，尤其是不用考虑一些靠近OS底层的通用功能，例如dark mode、自适应字体大小等。一年多没有写iOS了，看来又得花几天看看SwiftUI的教程和练练手，要不再过一年，想写写一些hobby的app都捡不起来了。糊口技术更新快是码农的现实。

Single code base: iPhone/iPad/Mac，以及新的iPadOS

iPad作为大屏幕iPhone的日子到头了，开始尝试覆盖一些MacBook的使用场景，慢慢变成一台触屏MacBook。我预言，三五年之后，MacBook将淡出，基本日常生活工作都可以在iPad上顺利进行（当然，在工作上，外接物理键盘估计免不了）。Mac Pro还是会有市场的，需要强大算力的工作，还是离不开desktop。

强大的新Pro和Monitor

这也是上面想法的一个不错的印证。

AR和Minecraft

还是半吊子，这样玩Minecraft手不累吗？AR的话，还是继续耐心等待几个版本之后的Hololens和Oculus。

Sign In with Apple

姗姗来迟。对于普通用户，又多了一个button。普通用户才不知道你后面在隐私方面做了多少改进，就是yet another button。对于大部分码农，这只支持苹果系统，在部署决策上一定属于二等公民。

 

iTunes分成三个app之类的，我不太关心，反正我从来就不喜欢iTunes，也不用iTunes。

觉得这次苹果中规中矩。之前还在纳闷苹果的软件部门都在干嘛，因为不见大飞跃，反而bug不断。原来团队里牛人的精力都集中在iPadOS之类的大方向迁移，那还算靠谱。

“Tesla autonomy day” 记录和想法

WeiranLeave a comment

Single vendor, move fast, tighter integration, easier regression test, less compatibility bugs. Every year from now, the performance charts will like the ones shown in Apple events. Chip is for self-driving focused, and then software is just for that chip.

特斯拉走的是苹果的路，就是所谓的walled garden。没有好坏。在这个阶段，无疑是可以缩短迭代周期。真心觉得特斯拉能私有化就更加完美，现在花太多精力在跟short sellers打嘴仗了。

这几年媒体报道都集中在model 3的产能和交付上，我以为特斯拉没有花心思在自动驾驶上，比较失望。因为我觉得推动电动汽车方面，特斯拉已经完成了历史使命。如果不去发展自动驾驶，那特斯拉可以从我视线消失了。没想到马斯克这个大嘴巴，能把在自动驾驶方面的突进守口如瓶，也是一个城府很深的人。

All production cars at this moment have the new computer installed.

这又是跟马斯克先狠吹的作风很不符，已经在路上跑了也不说，看来特斯拉完成了华丽转身。当各大厂还在讨论2020年推出第一款长续航电车的时候，特斯拉实际已经离开了那个战场。现在新战场的对手是waymo和uber。马斯克每次在新战场都很沉得住气的（参考spacex，boring，neuralink, starlink）。

“Anyone relied on LIDAR is doomed”.

The justification was that human beings drive with vision, not the laser. So autonomy can do the same. My argument would be, humans use vision, drive and kill 3,287 people every day. Don’t think Tesla autonomy affords to kill even 3 people a year. 同时，我也认同LIDAR的必要性不高。LIDAR可以解决很多由于探测精度带来的问题，但我很怀疑在当前特斯拉自动驾驶的诸多挑战里面，那些由探测精度引起的问题排不上前三，甚至排不上前十。与此同时，多个摄像头和硬件加速，可以一定程度代偿探测精度的不足。当简单的结构大量叠加，配合一定的算法，达到足够的冗余容错，可以逼近甚至超过复杂的单个系统。例子很多，简单的几种门电路组成的集成电路，低性能的廉价pc组成的强大的云计算，最近流行的深度学习。

Data collection is about large/various/real

Only annotate the better drivers.

纳闷特斯拉怎么定义better driver，好在哪里？这又从另外一个角度论证了特斯拉一定要卖保险给特斯拉的车主，从统计意义上的数据，理赔少的，基本就是better drivers了。

Robotaxi

Robotaxi是华丽转身，前面提到，我就不多说了。汽车本来就是一个把你从A点带到B点的移动铁箱而已，只是一个世纪的广告洗脑，汽车变成身份象征成功标志。当汽车作为一个容器，回归本质，拥有它的代价会不成比例的高时，可能只有王思聪可以养得起车了。

最后，我想了一下，如果真有私人车辆组成Robotaxi车队的日子，最大的痛点是什么？应该是儿童安全座椅。所以，快速适配特斯拉座位且可以方便折叠收纳的儿童安全座椅，销量会不错。当然了，那之后过不了多久，安全座椅甚至安全带，都会如同当年进电脑机房要穿的白大褂和要换的拖鞋一样，成为承载一段历史的物件。

蓝色起源的Blue Moon发布会

WeiranLeave a comment

近地行星地表面积实在很有限，移居其他行星解决不了问题。

所以必须要人造太空生态环境和城市。现在之所以发展不起来是因为没有太空建设的基础设施，亚马逊之所以能成功是因为起家的时候已经有物流电脑网络金融都已经是现成的。

蓝色起源使用氢燃料和垂直降落，都不是近地轨道观光需要挑战的，选择它们是因为氢燃料难但最强而且可以分解水来获得，为以后做准备，垂直降落难但容易拓展（越大的火箭越稳定）。

强调近地资源（月球）的可利用性。

使用燃料电池而不要太阳能，是因为月夜长的时候可以持续两周之久。

——

挺高兴看到最耀眼的两个大老板都很投入的发展太空探索，价值观和方法很不相同，但竞争是需要的，相互揶揄免不了。

我觉得不要用现在的科技，去过分假象以后的限制。例如，贝索斯说按照现在的能源需求，几十年之后我们就得吧太阳能铺满整个地球表面，来证明我们一定要找别的地方，而且还要很在意地表面积。先别说以后可能有可控核聚变之类的新能源，就算太阳能也有可能因为材料科学的突破而在单位面积的有效率上飞跃。感觉贝索斯跟马云一样，例如996ICU，道理有时候是这样，但从他们的嘴里说出来，就变得经不起推敲了。

UITableView concurrent issue with UIRefreshControl

WeiranLeave a comment

The Error 

The exception is thrown in

func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell

It complains about out of index. For example, indexPath.row is 8, but the data set is empty.

Troubleshooting

The function is called because somehow UI is being updated. But the data set is empty means the data is in the middle of being refreshed. UI shouldn’t be asked to update if data is being refreshed. So need to find out the code causing the UI update.

Root Cause

self.refreshControl.endRefreshing() is called too early in the wrong place of the sequence. Moved it to queryCompletionBlock solve the problem (while refreshing data from iCloud).