Reprint

call javascript in angular 7 https://stackoverflow.com/questions/53482324/how-can-i-use-javascript-code-in-angular-7

angular deploy to nginx ng build --aot “` server { listen 8081; server_name localhost; location / { root C:/website/angular/ng-prime/dist; // 这是angular生成的dist文件夹存放的位置 index index.html; try_files $uri $uri/ /index.html; // 注意此句，一定要加上。否则配置的子路由等无法使用 } error_page 500 502 503 504 /50x.html; location = /50x.html { root html; } } " https://www.cnblogs.com/kingkangstudy/p/8085642.html

‘markdown > PPT’ https://github.com/ksky521/nodeppt https://github.com/hakimel/reveal.js/

Java诊断工具 – Arthas Alibaba 开源的Java诊断工具 https://alibaba.github.io/arthas/

apr、apr-util, apr-iconv https://my.oschina.net/shawnplaying/blog/1518144 安装Apache的时候，为什么要安装apr和apr-util呢 要测APR给tomcat带来的好处最好的方法是在慢速网络上 (模拟Internet) ，将Tomcat线程数开到300以上的水平，然后模拟一大堆并发请求。如果不配APR，基本上300个线程狠快就会用满，以后的请求就只好等待。但是配上APR之后，并发的线程数量明显下降，从原来的300可能会马上下降到只有几十，新的请求会毫无阻塞的进来。 APR对于Tomcat最大的作用就是socket调度。 你在局域网环境测，就算是400个并发，也是一瞬间就处理/传输完毕，但是在真实的Internet环境下，页面处理时间只占0.1%都不到，绝大部分时间都用来页面传输。如果不用APR，一个线程同一时间只能处理一个用户，势必会造成阻塞。所以生产环境下用apr是非常必要的。 注: APR(Apache portable Run-time libraries，Apache可移植运行库)的目的如其名称一样，主要为上层的应用程序提供一个可以跨越多操作系统平台使用的底层支持接口库。 在早期的Apache版本中，应用程序本身必须能够处理各种具体操作系统平台的细节，并针对不同的平台调用不同的处理函数。随着Apache的进一步开发，Apache组织决定将这些通用的函数独立出来并发展成为一个新的项目。这样，APR的开发就从Apache中独立出来，Apache仅仅是使用APR而已。 一般情况下，APR开发包很容易理解为仅仅是一个开发包，不过事实上并不是。目前，完整的APR实际上包含了三个开发包: apr、apr-util以及apr-iconv，每一个开发包分别独立开发，并拥有自己的版本。

点数估算 敏捷开发点数估算 为什么用点数比用小时和天数更好？ 故事点数是通过对比以前开发过的大小相似的用户故事得到的。这种对比相对大小的估算方式，在有大量样本数据的情况下，比独立估算每个用户故事要准确得多。 举个例子，我们可以很容易的说出，从大连到长春的距离是从大连到沈阳的两倍，而不是大连到长春的距离是676.1千米， 大连到沈阳的距离是378.9千米。 (数据来自百度地图) 这样，团队不用花太多的时间来估算每个用户故事所要花费的准确时间和天数，就可以快速完成所有用户故事的估算。 不同的开发团队，是否可以使用统一的故事点数基准？ 不同的开发团队，对于故事点数有不同的度量基准，取决于各个团队所要估计的用户故事。除非他们是在开发相同的系统，否则团队A开发1个点的工作量和团队B在不同系统中开发1个点的工作量是不同的。这种差异将会影响团队的迭代交付速率。 如果有一个很大的项目，需要分成多个小团队来共同开发，人们很可能想去尝试定义一种点数标准应用到所有小团队。这有悖于估算用户故事点数的目的，每个小团队都会有自己的主观衡量标准。 我们如何估算试探性研究(Spike)的用户故事？ 为了弄明白如何实现一个特定的功能，或者验证某种概念，我们需要试探性研究故事 (Spike) 。由于很难知道到底总共需要多少工作量，通常我们要提前在团队中达成共识，对这种研究做出一定时间限制。这些用户故事可是通过观察交付速率趋势图，转换成大致的点数。 例如，如果需要计划一周的时间来完成一个试探性研究，而交付速率是16个点 (迭代周期为两周) ，那么就可以估算这个故事为8个点。 用户点数是否和业务价值有关？ 用户故事点数是对实现用户故事所需要工作量的团队内部度量。无论如何，与用户故事所能提供多少业务价值没有关系。 很可能在同一个系统中，1个点数的用户故事会比4个点的故事有更大的业务价值。业务价值最好是留给产品经理和相关的业务决策者来衡量。 在介绍敏捷估算的方法之前，我们先来回顾一下基于人天的传统估算的思路。传统的工作量估算是估计一个绝对值，单位是人天或者人时。 比如: David喝完一小杯热咖啡花费1.2个小时 (工作量 1.2人时) David喝完一大杯热咖啡花费2.4个小时 (工作量 2.4人时) 由于人的能力是有差异的，所以David的工作量对于Tom来讲可能就不适用，Tom喝完一小杯热咖啡可能需要1.5小时。这样一来，工作量、参与人以及完成这些工作的时间周期就是强相关的，因为强相关会带来如下挑战: 做计划时必须把人和周期关联到具体的任务上，会让计划很复杂。 团队成员的分工发生变化时对计划的影响比较大，管理和维护计划成本高。 (这是甘特图的价值所在 ) 由于第二条的原因，这种工作量的估算方式不利于团队协作。 接下来，我们来看看敏捷估算的思路。 在探讨具体的思路之前，我们先思考一下做估算的目的什么，通常有两个目的: 核算成本和周期，我们要了解这这个项目或产品的投资回报。 做计划，根据项目的需要，我们要知道什么时间点应该交付什么内容才可以满足市场、用户或客户的期望。 做敏捷估算时，请先忘掉人天或人时，敏捷估算关注的是工作量的规模 (大小) ，而不关心谁来做，不关心花多长时间做完。它的规模计量单位使用的是一个抽象的单位——故事点，故事点是一个相对值，是一个相对倍数，和人天，人时没有关系，它和公里、吨、摄氏度类似，只是一个计量单位而已。我们可以定义喝一小杯热咖啡花费的工作量为参考基准，是 1 个故事点。中杯看起来是小杯的2倍大，所以我们可以估算喝一中杯热咖啡花费的工作量是小杯的两倍， 是 2个故事点，大杯是小杯的三倍，所以工作量是3个故事点。 敏捷估算的步骤: 找一个参考基准，作为一个故事点。比如: 把开发一个简单的查询页面工作量作为基准，定义为一个故事点。 拿其它的故事和基准进行比较，估算他们之间的倍数，从而得到其它故事的故事点数。比如: 查看个人基本信息这个故事和开发一个简单的查询页面的规模差不多大，所以它也是1个点，录入个人基本资料的这个故事要复杂一些，大概时3个点。 3 . 累计产品backlog中的所有故事，得到所有故事总的故事点数。 得到了总的故事点规模，我们还要知道团队速度。团队速度是指: 1个敏捷团队在一个迭代中完成的故事点总数。比如: 某Scrum团队1个迭代可以完成 80个故事点，那么80个点就是他们的速度。 有了总的规模，我们也知道了团队一个迭代的速度，我们就可以很容易推算多少个迭代可以做完。 如下图所示，总的规模是1600个点，团队总共8个人，每个迭代完成80个点，我们就可以推算20个迭代完成。 每个迭代2周，所以40周可以完成，8个人40周的成本投入也可以很容易得出。 敏捷估算要点小结: 相对估算，使用故事点作为单位，故事点是一个相对倍数。 估算规模，规模的计量单位是故事点，规模和时间、周期无关，和人天，人时无关。 敏捷估算关注团队的速度，不关注单个人的速度。 通过总规模和团队速度，推算周期 http://www.yugusoft.com/article/%E6%95%8F%E6%8D%B7%E5%BC%80%E5%8F%91%E7%82%B9%E6%95%B0%E4%BC%B0%E7%AE%97.htm?f=blog_page https://cloud.tencent.com/developer/article/1104793

golang gin 重定向 https://www.cnblogs.com/zisefeizhu/p/12739223.html package main import ( "github.com/gin-gonic/gin" "net/http" ) func main() { r := gin.Default() //http重定向 r.GET("/index", func(c *gin.Context) { //c.JSON(http.StatusOK, gin.H{ // "status": "ok", //}) //跳转到sogo c.Redirect(http.StatusMovedPermanently, "https://www.sogo.com") }) //路由重定向 r.GET("/luyou", func(c *gin.Context) { //跳转到/luyou2对应的路由处理函数 c.Request.URL.Path = "/luyou2" //把请求的URL修改 r.HandleContext(c) //继续后续处理 }) r.GET("/luyou2", func(c *gin.Context) { c.JSON(http.StatusOK, gin.H{ "message":"路由重定向", }) }) r.Run(":9090") }

gin https://github.com/gin-gonic/gin#quick-start package main import ( "github.com/gin-gonic/gin" "net/http" ) func main() { router := gin.Default() router.GET("/path0", func(c *gin.Context) { firstname := c.DefaultQuery("params0", "Guest") lastname := c.Query("params1") // shortcut for c.Request.URL.Query().Get("lastname") c.String(http.StatusOK, "Hello %s %s", firstname, lastname) }) router.Run(":8080") }

kafka consumer 按照 Kafka 默认的消费逻辑设定，一个分区只能被同一个消费组（ConsumerGroup）内的一个消费者消费。 即同一个partition内的消息只能被同一个组中的一个consumer消费。当消费者数量多于partition的数量时，多余的消费者空闲 assignment, 分配策略 Kafka提供了消费者客户端参数partition.assignment.strategy用来设置消费者与订阅主题之间的分区分配策略。 默认情况下，此参数的值为：org.apache.kafka.clients.consumer.RangeAssignor，即采用RangeAssignor分配策略。除此之外，Kafka中还提供了另外两种分配策略： RoundRobinAssignor和StickyAssignor。消费者客户端参数partition.asssignment.strategy可以配置多个分配策略，彼此之间以逗号分隔。 RangeAssignor RangeAssignor 策略的原理是按照消费者总数和分区总数进行整除运算来获得一个跨度，然后将分区按照跨度进行平均分配，以保证分区尽可能均匀地分配给所有的消费者。对于每一个topic，RangeAssignor策略会将消费组内所有订阅这个topic的消费者按照名称的字典序排序，然后为每个消费者划分固定的分区范围，如果不够平均分配，那么字典序靠前的消费者会被多分配一个分区。 range assignor 在某些情况下会分配不均匀, 有可能会出现部分消费者过载的情况. RoundRobinAssignor 把 topic 和 consumer 排序, 依次给 topic 分配 consumer, 同一个 topic 中的不同 partition 分被均匀分配给不同的 consumer. RoundRobinAssignor 策略的原理是将消费组内所有消费者以及消费者所订阅的所有topic的partition按照字典序排序，然后通过轮询消费者方式逐个将分区分配给每个消费者。RoundRobinAssignor策略对应的partition.assignment.strategy参数值为：org.apache.kafka.clients.consumer.RoundRobinAssignor。 如果同一个消费组内所有的消费者的订阅信息都是相同的，那么RoundRobinAssignor策略的分区分配会是均匀的。 如果同一个消费组内的消费者所订阅的Topic 是不相同的，那么在执行分区分配的时候就不是完全的轮询分配，有可能会导致分区分配的不均匀。如果某个消费者没有订阅消费组内的某个topic，那么在分配分区的时候此消费者将分配不到这个topic的任何分区。 StickyAssignor “sticky”这个单词可以翻译为“粘性的”，Kafka从0.11.x版本开始引入这种分配策略，它主要有两个目的： ① 分区的分配要尽可能的均匀； ② 分区的分配尽可能的与上次分配的保持相同。 当两者发生冲突时，第一个目标优先于第二个目标。鉴于这两个目标，StickyAssignor策略的具体实现要比RangeAssignor和RoundRobinAssignor这两种分配策略要复杂很多。 从结果上看StickyAssignor策略比另外两者分配策略而言显得更加的优异，这个策略的代码实现也是异常复杂，如果大家在一个 group 里面，不同的 Consumer 订阅不同的 topic, 那么设置Sticky 分配策略还是很有必要的。 properties.put("enable.auto.commit", "true"); properties.put("auto.commit.interval.ms", "1000"); properties.put("auto.offset.reset", "latest"); properties.put("session.timeout.ms", "30000"); properties.put("key.deserializer", "org.apache.kafka.common.serialization.StringDeserializer"); properties.put("value.deserializer", "org.apache.kafka.common.serialization.ByteArrayDeserializer"); Consumer Group 主要用于实现高伸缩性，高容错性的 Consumer 机制。因此，消息的接收是基于 Consumer Group 的。组内多个 Consumer 实例可以同时读取 Kafka 消息，同一时刻一条消息只能被一个消费者消费，而且一旦某一个 consumer “挂了”， Consumer Group 会立即将已经崩溃的 Consumer 负责的分区转交给其他 Consumer 来负责。从而保证 Consumer Group 能够正常工作。 ...

css scss sass less stylus Sass和Less语法严谨、Stylus相对自由。因为Less长得更像 css，所以它可能学习起来更容易。 Sass 和 Compass、Stylus 和 Nib 都是好基友。 Sass 和 Stylus 都具有类语言的逻辑方式处理: 条件、循环等，而 Less 需要通过When等关键词模拟这些功能，这方面 Less 比不上 Sass 和 Stylus。 Less 在丰富性以及特色上都不及 Sass 和 Stylus Stylus，它的语法自由度很高，而且写出来的代码非常简洁. https://zhuanlan.zhihu.com/p/23382462

vscode, code-server code server 是 coder 公司基于微软开源的 Visual Studio Code 开发的一款产品。 code server 的目标是为开发者构建一个便捷统一的开发环境，让开发者能从任意设备、任意位置通过浏览器来进行代码的编写。从而免去了常规的 IDE 开发流程中的环境搭建的问题。 code server 有哪些优点？ 环境统一 code server 解决的第一个问题就是跨设备的环境一致性。因为 code server 始终运行在一个远程的云端环境，因此他的开发环境始终是一致的，不会出现不同平台或者不同设备运行相同的代码而出现各种问题的情况。 我相信有不少程序员遇到过类似的问题。比如，同样的代码在 MacOS 上运行正常，在 Windows 上运行报错；或者在同事 A 的电脑上运行正常，而在同事 B 的电脑上运行报错。 而 code server 解决了这个问题，对于同一个项目的代码开发，不管是谁，运行代码的环境都是 code server 所在的服务器环境，这有效的避免的环境不同带来的问题，让程序员把精力更多地放在代码编写上，而不是去解决各种平台切换带来的问题上。 podman run -d --name code-server \ -p 8080:8080 \ -v "code-server-config:/root/.config" \ -v "code-server-project:/home/coder/project" \ -v "code-server-ssh:/root/.ssh" \ -v "code-server-data:/data" \ -u "$(id -u):$(id -g)" \ -e "DOCKER_USER=root" \ --memory=2g \ --cpus=1 \ codercom/code-server:3.12.0 --auth none nginx 配置 location / { proxy_pass http://wyse5070.wiloon.com:8080; proxy_set_header Host $host; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection upgrade; proxy_set_header Accept-Encoding gzip; } ...

nginx gzip https://juejin.im/post/5b518d1a6fb9a04fe548e8fc

MySQL, sql_mode http://xstarcd.github.io/wiki/MySQL/MySQL-sql-mode.html MySQL的sql_mode合理设置 目录 http://dev.MySQL.com/doc/refman/5.7/en/sql-mode.html http://blog.csdn.net/wyzxg/article/details/8787878 当前sql-mode设置 查看当前sql-mode SELECT @@GLOBAL.sql_mode; SELECT @@SESSION.sql_mode; MySQL> SELECT @@GLOBAL.sql_mode; +—————+ | @@GLOBAL.sql_mode | +—————+ | STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION | +—————+ 1 row in set (0.00 sec) MySQL> SELECT @@SESSION.sql_mode; +—————+ | @@SESSION.sql_mode | +—————+ | STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION | +—————+ 1 row in set (0.00 sec) 设置当前sql-mode SET GLOBAL sql_mode = ‘modes…’; SET SESSION sql_mode = ‘modes…’; my.cnf中配置sql-mode [MySQLd] set the SQL mode to strict sql-mode=“modes…” sql-mode = “STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION” sql_mode常用值 ONLY_FULL_GROUP_BY: ...

Brotli https://segmentfault.com/a/1190000009374437 使用Brotli提高网站访问速度 在优化网站打开速度上，我们有很多的方法，而其中一个就是减少诸如Javascript和CSS等资源文件的大小，而减少文件大小的方法除了在代码上下功夫外，最常用的方法就是使用压缩算法对文件进行压缩。 目前，网站普遍使用的是gzip压缩算法，当然你可能还知道deflate和sdch算法，但是最近两年新兴了一个新的压缩算法: Brotli，下面我将会对这个算法进行简单的介绍。 什么是Brotli Brotli最初发布于2015年，用于网络字体的离线压缩。Google软件工程师在2015年9月发布了包含通用无损数据压缩的Brotli增强版本，特别侧重于HTTP压缩。其中的编码器被部分改写以提高压缩比，编码器和解码器都提高了速度，流式API已被改进，增加更多压缩质量级别。新版本还展现了跨平台的性能改进，以及减少解码所需的内存。 与常见的通用压缩算法不同，Brotli使用一个预定义的120千字节字典。该字典包含超过13000个常用单词、短语和其他子字符串，这些来自一个文本和HTML文档的大型语料库。预定义的算法可以提升较小文件的压缩密度。 使用brotli取代deflate来对文本文件压缩通常可以增加20%的压缩密度，而压缩与解压缩速度则大致不变。 浏览器支持情况 图片描述 Chrome从版本49开始支持，但是完整的支持是在版本50 (2016年5月27日开始支持) 。 Firefox从版本52开始支持。 IE全版本不支持，但是Edge从版本15开始支持。 Safari全系不支持。 Opera从版本44开始支持。 支持Brotli压缩算法的浏览器使用的内容编码类型为br，例如以下是Chrome浏览器请求头里Accept-Encoding的值: Accept-Encoding: gzip, deflate, sdch, br 如果服务端支持Brotli算法，则会返回以下的响应头: Content-Encoding: br 需要注意的是，只有在HTTPS的情况下，浏览器才会发送br这个Accept-Encoding。 关于性能 下面是LinkedIn做的一个性能测试结果: enter image description here Algorithm Quality Compression Time (ms) Decompression Time (ms) gzip 6 169 35 gzip 9 284 27 zopfli 15 37,847 32 zopfli 100 194,460 38 zopfli 1000 1,855,480 29 brotli 4 109 24 brotli 5 193 20 ...

goland build constraints exclude all go files in syscall/js go to Settings (Preferences) | Go | Vendoring & Build Tags and then select OS -> js and ARCH -> wasm. https://youtrack.jetbrains.com/issue/GO-6128

‘Java Builder’ https://juejin.im/entry/5b83fe1851882542e16bfcf6 Java 中的 Builder 模式和协变返回类型 阅读 735 收藏 45 2018-08-27 原文链接: www.codebelief.com 阅读这篇文章大约需要五到十分钟时间。 Builder 模式是一种创建型的设计模式，即解决对象的创建问题。 在 Java、C++ 这类语言中，如果一个类在创建时存在可选参数，那么可以通过函数重载来实现，但是如果可选参数非常多的话，构造函数的数量也会变得非常多，并且可能因为不同可选参数类型相同而没法重载，我们接下来通过例子来说明。 一、可选参数带来的问题 不可重载的情况 //学号、姓名是必须参数，身高、体重可选 public Student(int id, String name) {} public Student(int id, String name, float height, float weight) {} public Student(int id, String name, float height) {} //只填身高 public Student(int id, String name, float weight) {} //只填体重 (签名重复，无法重载) 虽然最后两个构造方法参数名不同，但是它们类型相同，方法签名也就相同，因此没办法重载，只能保留一个。 构造方法数量过多 接着考虑这么一个场景，你正在设计一个 Person 类，这个类存放了 name、age、sex 等信息，其中 name 是必要信息，而 age 和 sex 是可选信息，那么你可能会编写如下的构造方法: ...

Kafka, offset offset的保存 一个消费组消费partition，需要保存offset记录消费到哪，以前保存在zk中，由于zk的写性能不好，以前的解决方法都是consumer每隔一分钟上报一次。这里zk的性能严重影响了消费的速度，而且很容易出现重复消费。 在0.10版本后，kafka把这个offset的保存，从zk总剥离，保存在一个名叫__consumeroffsets topic的topic中。写进消息的key由groupid、topic、partition组成，value是偏移量offset。topic配置的清理策略是compact。总是保留最新的key，其余删掉。一般情况下，每个key的offset都是缓存在内存中，查询的时候不用遍历partition，如果没有缓存，第一次就会遍历partition建立缓存，然后查询返回。 作者: 123archu 链接: https://www.jianshu.com/p/d3e963ff8b70 来源: 简书 简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。 https://blog.csdn.net/u012129558/article/details/80075270 对Kafka offset的管理，一直没有进行系统的总结，这篇文章对它进行分析。 什么是offset offset是consumer position，Topic的每个Partition都有各自的offset. Keeping track of what has been consumed, is, surprisingly, one of the key performance points of a messaging system. Most messaging systems keep metadata about what messages have been consumed on the broker. That is, as a message is handed out to a consumer, the broker either records that fact locally immediately or it may wait for acknowledgement from the consumer. This is a fairly intuitive choice, and indeed for a single machine server it is not clear where else this state could go. Since the data structure used for storage in many messaging systems scale poorly, this is also a pragmatic choice-since the broker knows what is consumed it can immediately delete it, keeping the data size small. ...

goexec `bash goexec ‘strings.Repeat(“Go! “, 5)’ goexec ‘http.ListenAndServe(":8080”, http.FileServer(http.Dir(”.")))'` https://github.com/shurcooL/goexec#goexec

golang WebAssembly https://github.com/golang/go/wiki/WebAssembly https://tutorialedge.net/golang/go-webassembly-tutorial/ package main import "fmt" func main() { fmt.Println("Hello, WebAssembly!") } gOOS=js GOARCH=wasm go build -o main.wasm cp "$(go env GOROOT)/misc/wasm/wasm_exec.js" . go get -u github.com/shurcooL/goexec goexec 'http.ListenAndServe(":8080", http.FileServer(http.Dir(".")))'

golang kafka https://github.com/Shopify/sarama https://github.com/bsm/sarama-cluster