w1100n
This site is best viewed in Google Chrome
wiloon, 5/31/2019 12:54

https://github.com/ksky521/nodeppt https://github.com/hakimel/reveal.js/

wiloon, 5/30/2019 18:31

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

wiloon, 5/30/2019 9:51

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,每一个开发包分别独立开发,并拥有自己的版本。

wiloon, 5/28/2019 8:18

敏捷开发点数估算 为什么用点数比用小时和天数更好? 故事点数是通过对比以前开发过的大小相似的用户故事得到的。这种对比相对大小的估算方式,在有大量样本数据的情况下,比独立估算每个用户故事要准确得多。 举个例子,我们可以很容易的说出,从大连到长春的距离是从大连到沈阳的两倍,而不是大连到长春的距离是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 . … Continue reading

wiloon, 5/25/2019 11:19

https://auth0.com/blog/developing-golang-and-angular-apps-part-2-angular-front-end/

gin
wiloon, 5/23/2019 21:31

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”) }

wiloon, 5/21/2019 10:54

https://www.cnblogs.com/huxi2b/p/6223228.html Kafka消费组(consumer group) 一直以来都想写一点关于kafka consumer的东西,特别是关于新版consumer的中文资料很少。最近Kafka社区邮件组已经在讨论是否应该正式使用新版本consumer替换老版本,笔者也觉得时机成熟了,于是写下这篇文章讨论并总结一下新版本consumer的些许设计理念,希望能把consumer这点事说清楚,从而对广大使用者有所帮助。 在开始之前,我想花一点时间先来明确一些概念和术语,这会极大地方便我们下面的讨论。另外请原谅这文章有点长,毕竟要讨论的东西很多,虽然已然删除了很多太过细节的东西。 一、 误区澄清与概念明确 1 Kafka的版本 很多人在Kafka中国社区(替群主做个宣传,QQ号:162272557)提问时的开头经常是这样的:“我使用的kafka版本是2.10/2.11, 现在碰到一个奇怪的问题。。。。” 无意冒犯,但这里的2.10/2.11不是kafka的版本,而是编译kafka的Scala版本。Kafka的server端代码是由Scala语言编写的,目前Scala主流的3个版本分别是2.10、2.11和2.12。实际上Kafka现在每个PULL request都已经自动增加了这三个版本的检查。下图是我的一个PULL request,可以看到这个fix会同时使用3个scala版本做编译检查: 目前广泛使用kafka的版本应该是这三个大版本:0.8.x, 0.9.x和0.10.* 。 这三个版本对于consumer和consumer group来说都有很大的变化,我们后面会详谈。 2 新版本 VS 老版本 “我的kafkaoffsetmonitor为什么无法监控到offset了?”——这是我在Kafka中国社区见到最多的问题,没有之一!实际上,Kafka 0.9开始提供了新版本的consumer及consumer group,位移的管理与保存机制发生了很大的变化——新版本consumer默认将不再保存位移到zookeeper中,而目前kafkaoffsetmonitor还没有应对这种变化(虽然已经有很多人在要求他们改了,详见https://github.com/quantifind/KafkaOffsetMonitor/issues/79),所以很有可能是因为你使用了新版本的consumer才无法看到的。关于新旧版本,这里统一说明一下:kafka0.9以前的consumer是使用Scala编写的,包名结构是kafka.consumer.,分为high-level consumer和low-level consumer两种。我们熟知的ConsumerConnector、ZookeeperConsumerConnector以及SimpleConsumer就是这个版本提供的;自0.9版本开始,Kafka提供了java版本的consumer,包名结构是o.a.k.clients.consumer.,熟知的类包括KafkaConsumer和ConsumerRecord等。新版本的consumer可以单独部署,不再需要依赖server端的代码。 二、消费者组 (Consumer Group) 1 什么是消费者组 其实对于这些基本概念的普及,网上资料实在太多了。我本不应该再画蛇添足了,但为了本文的完整性,我还是要花一些篇幅来重谈consumer group,至少可以说说我的理解。值得一提的是,由于我们今天基本上只探讨consumer group,对于单独的消费者不做过多讨论。 什么是consumer group? 一言以蔽之,consumer … Continue reading

wiloon, 5/19/2019 13:34

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

wiloon, 5/19/2019 9:52

docker run -d \ –name code-server \ -p 38443:8443 \ -v “code-server-project:/home/coder/project” \ codercom/code-server \ –allow-http –no-auth https://github.com/cdr/code-server https://hub.docker.com/r/codercom/code-server

wiloon, 5/16/2019 19:59

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

wiloon, 5/16/2019 13:26

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 1 2 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 | +——————————————–+ | … Continue reading

wiloon, 5/15/2019 9:03

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 … Continue reading

wiloon, 5/13/2019 18:59

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 … Continue reading

wiloon, 5/13/2019 10:42

Round Robin 轮询调度算法 轮询调度(Round-Robin Scheduling) 轮询调度(Round Robin Scheduling)算法就是以轮询的方式依次将请求调度不同的服务器,即每次调度执行i = (i + 1) mod n,并选出第i台服务器。算法的优点是其简洁性,它无需记录当前所有连接的状态,所以它是一种无状态调度。 轮询调度算法的原理是每一次把来自用户的请求轮流分配给内部中的服务器,从1开始,直到N(内部服务器个数),然后重新开始循环。 轮询调度算法流程 假设有一组服务器N台,S = {S1, S2, …, Sn},一个指示变量i表示上一次选择的服务器ID。变量i被初始化为N-1。一个很经典的算法程序如下: j = i; do { j = (j + 1) mod n; i = j; return Si; } … Continue reading

wiloon, 5/13/2019 10:32

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 … Continue reading

wiloon, 5/13/2019 9:00

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

wiloon, 5/10/2019 18:19

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(“.”)))’

wiloon, 5/10/2019 16:59

https://github.com/bsm/sarama-cluster

wiloon, 5/10/2019 14:51

Kafka是什么 Kafka是最初由Linkedin公司开发,是一个分布式、分区的、多副本的、多订阅者,基于zookeeper协调的分布式日志系统(也可以当做MQ系统),常见可以用于web/nginx日志、访问日志,消息服务等等,Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。 1.前言 一个商业化消息队列的性能好坏,其文件存储机制设计是衡量一个消息队列服务技术水平和最关键指标之一。 下面将从Kafka文件存储机制和物理结构角度,分析Kafka是如何实现高效文件存储,及实际应用效果。 2.Kafka文件存储机制 Kafka部分名词解释如下: Broker:消息中间件处理结点,一个Kafka节点就是一个broker,多个broker可以组成一个Kafka集群。 Topic:一类消息,例如page view日志、click日志等都可以以topic的形式存在,Kafka集群能够同时负责多个topic的分发。 Partition:topic物理上的分组,一个topic可以分为多个partition,每个partition是一个有序的队列。 Segment:partition物理上由多个segment组成,下面2.2和2.3有详细说明。 offset:每个partition都由一系列有序的、不可变的消息组成,这些消息被连续的追加到partition中。partition中的每个消息都有一个连续的序列号叫做offset,用于partition唯一标识一条消息. 分析过程分为以下4个步骤: topic中partition存储分布 partiton中文件存储方式 partiton中segment文件存储结构 在partition中如何通过offset查找message 通过上述4过程详细分析,我们就可以清楚认识到kafka文件存储机制的奥秘。 2.1 topic中partition存储分布 假设实验环境中Kafka集群只有一个broker,xxx/message-folder为数据文件存储根目录,在Kafka broker中server.properties文件配置(参数log.dirs=xxx/message-folder),例如创建2个topic名称分别为report_push、launch_info, partitions数量都为partitions=4 存储路径和目录规则为: 复制代码 xxx/message-folder |–report_push-0 |–report_push-1 |–report_push-2 |–report_push-3 |–launch_info-0 |–launch_info-1 |–launch_info-2 |–launch_info-3 复制代码 在Kafka文件存储中,同一个topic下有多个不同partition,每个partition为一个目录,partiton命名规则为topic名称+有序序号,第一个partiton序号从0开始,序号最大值为partitions数量减1。 如果是多broker分布情况,请参考kafka集群partition分布原理分析 2.2 partiton中文件存储方式 … Continue reading

next page
辽ICP备14012896