-
Java Streaming Basic
10年前加入现在的公司的时候公司的产品还在用JDK5，写code自然完全不会用Lamda，Streaming这些8才出现的特性。 后来开始做micro service了，用到新版本的JDK，但是我也很少写code了。中间看了一些书，不过一直是似是而非。是时间仔细看下了。 Intermediate Operations filter limit map flatMap Stream.map和Stream.flatMap的区别 先看signature. 区别是 flatMap穿进去一个Item，出来一个Stream: 这两个其实是完全不一样的东西，map就是把steam里面的item转换成另外一个，非常简单。flatMap是用来处理item也是list的情况，有时候我们想把两维列表转化成一个，就可以用这。下面是一个简单的例子： 下面是项目的一个更加实际的例子: 这个例子是拿到一个父对象，父对象里面有子对象，这样就能拿到所有的子对象。 总的来说stream就是一个循环，而flatMap就是一个嵌套循环。 下面是另外一个lamda的例子（不是method reference): Terminal Operation forEach forEach其实就是iterate.不用改被用作计算，就是用简单的report，或者简单的操作比如把结果加到另一个colection里面. –<Effective Java> collect 常用的的下面几种: toList toSet toMap：如果有重复key，会出错。第三个参数可以用来去重。比如可以选择最大，选择最后的一个。 groupingBy：Value可以是一个数组，也可以是summary，比如`counting()`. Joining: 三个参数，join的delimiter, start character，end character
-
Docker的权限控制
昨天晚上几个小时折腾一个docker上的mysql数据库的问题，最后发现根本原因是自己脑残把docker的目录的权限写成777. 由此导致了一系列问题。 事情的起因是想给mysql加一些参数，限制总的binlog的size。因为昨天发现磁盘空间被mysql用完然后导致这个网站down机。。 本来加一个参数很简单的事情，但是修改了/etc/my.cnf 之后发现参数并没有生效。于是各种研究，后来发现在log里面显示由于my.cnf的权限是全局可写，然后mysql自动忽略了这个配置文件而用缺省文件。所以所有的添加到my.cnf里面的信息自然不会生效。 在这里的时候完全没想到是因为自己把docker的目录改成777导致了，心里却在埋怨做image的人怎么留下了这个bug。于是上手又是用volume map本地的my.cnf到远程（我的docker daemon是run在远程linux下），又是直接修改my.cnf的权限。终于配置文件生效了。但是tungsten replicator怎么样也连接不到mysql。于是添加ssl=0 试图disablessl，但是又遇到无效caching_sha2_password的问题. 搜索文档还要修改用户的默认密码存放方式，想修改还是不成功，还要修改system db的engine。。 因为在这开始之前，我的tungsten replicator 通过修改ssl的方式就可以连接，完全没有做那些繁琐的操作，于是开始怀疑到底哪里出错，为什么这次需要这么复杂。 2个小时以后开始怀疑可能是/etc/my.cnf的权限问题不是image的问题，而是我做了777导致了。又做了一些尝试终于算是解释了所有的现象: 由于错误的使用777，导致mysql image初始化的时候使用了默认的参数配置，这就是为什么当我之后再修改my.cnf的配置的时候已经晚了，因为缺省配置很多时候是没办法初始化之后修改的。比如说创建用户的时候的密码设定( 应该是“mysql_native_password“而不是缺生的”caching_sha2_password”). Volume映射的时候文件权限默认使用的是宿主的文件权限。我的docker compose文件在mac，docker engine在linux。最终的映射是 mac -> linux host -> container. 这中间还有一个把nas的文件映射到linxus host上的过程（这里也出现了一些问题，docker后来莫名其面起不来某些container，原来是我的nas映射出问题了，重启mac电脑解决。。） 中间试图修改docker的文件目录权限，但是发现太麻烦，潜在的问题太多，因为我也不知道最早的文件的权限是啥。所以干脆删除所有的目录，让docker重现下载image，重建目录。问题解决。 经验总结 要及时document各种步骤。我之前通过ssl=0解决了tungsten的链接问题，但是昨晚改动，工作了就没有document。结果几天以后自己都忘了自己做了什么，只记得在mysql上改了一个配置。当后来出现问题的时候，因为不确定之前怎么工作的，导致浪费了很多时间。 现在的docker 貌似是run在linux，但是由于使用docker compose运行很多containers，而docker compose文件是在mac，而且volume的映射最终是在mac （mac->linux host)，所以docker 还是没办法脱离mac电脑而在远程执行。只能说runtime的话有linux host就好了，但是要做操作修改，还是要在mac端完成。 用Docker也有几年时间，但是没有真的很系统的学习，其实可能只需要认真花一两天看看书，很多我今天遇到的问题都不会出现。与其花时间debug问题还不如把基础打牢啊。。
-
一些面试算法中的Java基本操作运算
很久没有真的写程序，一些基本的Utils的使用也淡忘了。这里总结一下: 数组 数组转化成List List转化为数组 排序数组 排序List 打印一维数组 打印多于一维数组 打印List 答应list里面含有array MAP Merge Print a map 其他 boolean的值只能是true，false，而不能是0，1. char是用单引号: char abc=’a’;
-
软件工程师的职业发展
由jun-rao的职业生涯想起来”>由Jun Rao的职业生涯想起来 最近在看”Kafka The Definitive Guide”这本书。里面的作者之一是kafka最早的开发者。书中讲到了最早项目是如何开始的。提到Jay Kreps带领团队，其中一个是熟的作者（Neha），还提到了一个中国人的名字” Jun Rao”。 忍不住上网搜了一下这个人。下面截图他的工作经历: 89年清华本科毕业，然后去哥伦比亚大学读博士，一直到2000年。第一份在IBM的工作工作了10年，然后在加入LinkedIn4年，在LinkedIn的时候是Senior Staff Engineer, IBM的是Research Staff Member. 从LinkedIn离职以后作为cofounder加入Confluent，还是做Kafka相关的工作。 看到他的经历可能能感受到他在IBM 10年的不得志，加入LinkedIn就是一个转机吧。有时候就是需要一个契机，如果没有LinkedIn的机会，可能他也就像无数的在硅谷打工的软件工程是一样的职业历程。 有时候靠的是机遇，但是更多的还是要寻求自我的突破和探索新的领域的勇气吧。 和所有还想折腾的人共勉。
-
如何在AWS中提供API服务
这里讲如何通过利用AWS提供的基础服务对外提供Service。从域名解析到Load Balancer,再到Docker Container的端口映射。 下面是结构图。 以下是几点说明: Loader Balancer 定义了internal的DNS Name (比如说:internal-daco-sbx08-102899950.us-west-2.elb.amazonaws.com ) . Route 53的 Hosted Zone里面的records就是把外部域名解析到内部的DNS Load Balancer分三种. Application Load Balancer 是HTTP级别的，Network Load Balancer是TCP级别的。 ALB可以做端口映射，并根据http header（上面的例子是Host)，把请求分发到Target Group. Target Group定义了外部的端口，然后管理外部端口到instance的端口。通常target group的端口和instance的端口是一样的（如果在task definition也就是docker container里面映射了外部端口），也可能不一样(如果没有映射）. Target Group, Service是1:1映射。Target Group会提供health check定时check是不是健康。Task内部实现约定API，做实际check. ECS, ASG, Lauch Configuration协同工作，各司其职，提供服务和scaling，monitor等各种管理。 疑问 貌似没有配置load balancer的数量。难道这里从来不会是系统瓶颈？ 关于Target Group的外部端口和docker container（task）的内部端口是一对一映射，还是随机映射，而让target group自己管理，不知道哪个是best practice。
-
Two Sum算法的小trick（Leetcode的premium的解答没有讲到的)
最开始其实想说一下Leedcode提供的实现的代码质量其实真的一般，如果有人面试的时候用实例代码的风格，我估计算法写的再好也没太大用。最简单的变量命名。尽然有这样的代码: Map<Integer, Integer> map = new HashMap<>(); 每定义一个变量都要花时间至少稍微想一个变量命名，这是一个最基本的习惯。写出用map作为变量名的人绝对不是有经验的好工程师应该做的事情。 好了，言归正传。 Two Sum可以算是算法题里面最简单的之一了。下面是题目和LeetCode Premium给出的一个SolutionO(N) Solution. 题目:Given an array of integers nums and an integer target, return indices of the two numbers such that they add up to target.You may assume that each input would have exactly one solution, and you may not use the same element twice.You can return the answer in any order. 下面是采用Two Pass的 O(N)时间复杂度的解答: To improve our runtime complexity, we need a more efficient way to check if the complement exists in the array. If the complement exists, we need to get its index. What is the best way to maintain a mapping of each element in the array…
-
AWS 花费知多少
很久没有关注AWS的花费了，一个不相干的会忽然让我想起来可以去看一下。 下面是公司一个单独服务的一个月的花费： DynamoDB在项目中就是存储一些简单的audit，花费却是最多的一项。写花了7k多，而读只是185.说明存了却没用😂。 EC2提供基本服务，用得多倒是也正常。ElastiCache其实有点浪费了，很多东西其实可以用其他方式存取，DynamoDB应该可以满足大部分的需求。DynmoadDB的存储挺贵的，应该可以删掉90%。RDS数据库应该也算是相对合理。 EC2 Transfer是跨region的花费，其实应该可以避免的。 所有服务的参考:
-
如何在Linux访问Mac文件系统
如果你在家里自己搭建了一个Linux服务器，有时候需要把本地Mac笔记本里面的文件映射到远程linux服务器。比如说你需要： 在远程Linux运行docker，docker有时候需要把本地的文件目录mount到container里面。但是这个时候docker engine的本地其实是linux服务器。这个时候就需要两次link。把mac的文件目录mount到远程linux，然后再通过docker把linux的host目录mount到container。 单纯的文件拷贝。这个比scp要方便。 做法其实很简单，就是修改’etc/fstab’，加上下面这行： 192.168.103.168:/System/Volumes/Data/Users/abc /mnt/abcMap nfs defaults 0 0 这种做法默认是没有写的权限，如果需要写的权限，不能直接用chmod在linux下改，而是需要在mac电脑上用chmod把其他用户组也授予写的权限。 注意当添加子目录的时候，mac默认是其他用户组还是没有权限，这时候每添加一个新的目录，就需要再修改一次权限。
-
不写code的技术经理不是好经理😄
来美国6年了，基本上没有写过什么code。大多数时间就是做一些high level的 design，项目的协调，帮助解决客户问题和各种杂事。真的没有时间专心看技术，写code。 最近难得有机会，在没有打扰的情况下自己学一些东西，写一些东西，纯技术。还真的有一种欲罢不能的感觉。😂 挺好的，忽然觉得以前的那些时间是不是白白浪费了。。 作为技术经理，如果对于技术本身没有第一手的信息，特别是现在技术发展这么快的情况下，很多情况下，做出的决定，提出的方向可能就会落伍。如果组里面有很强的技术人员当tech lead还好一些，如果组里面都是年轻人，那这样的没有第一手经验的经理其实很难带出一个有效率的团队。 给自己加个油！
-
理想和现实的差距 – Redis的近似LRU
最近看一些算法题，各种时间复杂度，空间复杂度充斥脑海。O(N), O(N^2), O(NLogN)。这里拿LRU(Least Recently Used)算法来举一个例子算法和实际的差别。 这个是Leetcode里面的算法: https://leetcode.com/problems/lru-cache/. 没有兴趣的人其实也不用看，基本上就是设计一个LRU算法，保证读取和插入的时间复杂度都是O(N). 代码基本上也就100行左右，貌似很简单。但是如果看Redis的文档我们会发现这段话： https://redis.io/topics/lru-cache Redis LRU algorithm is not an exact implementation. This means that Redis is not able to pick the best candidate for eviction, that is, the access that was accessed the most in the past. Instead it will try to run an approximation of the LRU algorithm, by sampling a small number of keys, and evicting the one that is the best (with the oldest access time) among the sampled keys. 既然算法这么简单为什么Redis的默认实现不去做严格的LRU呢？其实原因很简单，为了节省空间。在传统的时间和空间复杂度里面，所有的非指数级的增长都被归纳成一个结果。比如说O(N) 和 O(2n)，或者更夸张的O(100N)或者更多。这在实际中能是一样的？使用double的空间，花费double的时间，再怎么说也不一样的。