关于密码你不知道的冷知识?至今还有 3% 的人使用“123456”作为密码

fanta2 发表了文章 • 0 个评论 • 79 次浏览 • 2021-02-04 10:11 • 来自相关话题

之前我们报导过 2020年被用烂大街的密码《2020 最烂密码 TOP 200 曝光!》,500 多万个泄漏密码表明,共有近 3% 的人使用“123456”作为密码。而最近知名黑客网站 Have I Been Pwned 上一个密码“ji32k7au4a83”... ...查看全部

之前我们报导过 2020年被用烂大街的密码《2020 最烂密码 TOP 200 曝光!》,500 多万个泄漏密码表明,共有近 3% 的人使用“123456”作为密码。而最近知名黑客网站 Have I Been Pwned 上一个密码“ji32k7au4a83”的使用次数引起了热烈讨论。

Have I Been Pwned 是一个可以查询用户的邮箱是否被泄漏的网站,它的一个密码查询功能 Pwned Passwords 记录着在数据泄露中暴露的 551 509 767 个真实密码,用户可以在这里查询某个密码被使用的次数。比如查询一下 2018 年最烂密码“123456”,得到 23 174 662 次的结果:

1.jpg

“123456”这样简单易记的数字串被很多人作为密码使用,这很容易理解,但是有一个密码 “ji32k7au4a83”的使用次数让人费解,并且在最近引起了热烈讨论。

硬件/软件工程师 Robert Ou 最开始在 Pwned Passwords 上发现“ji32k7au4a83”竟然有 141 次使用,他觉得这不太正常,因为这个字符串太“偏”了,于是他在社区提问。

随后就有人指出了原因(估计就是使用者),原来“ji32k7au4a83”是汉语注音符号系统中“我的密码”的对应字符串。

汉语注音符号是以章太炎的记音字母作蓝本,1913 年由中国读音统一会制定,1918 年北洋政府教育部正式颁行的一套注音系统。

2.png

1918 年第一个版本如下:

声母介音韵母
ㄍㄎㄫㄐㄑㄬㄉㄊㄋㄅㄆㄇㄈㄪㄗㄘㄙㄓㄔㄕㄏㄒㄌㄖㄧㄨㄩㄚㄛㄝㄟㄞㄠㄡㄢㄤㄣㄥㄦ

经过一个多世纪的发展,目前注音符号已经变化不少。目前中国台湾、澎湖、金门与马祖仍在使用注音符号,详情可以查看百科。

3.jpg

以上中招的朋友看完本文请记得修改密码。

据说,黑客会根据网民习惯设置的密码,收集起来编写成为“常用密码库”,直接使用现成的常用密码库去匹配破解,往往就能短时间破解大量账号。有安全机构研究显示,黑客大约只要17分钟就可以破解1000个帐号。

那我们平时该如何去设置密码呢?

安全专家的建议是,设置密码满足这三点:

  1. 密码长度最好8位或以上;

  2. 密码没有明显的组成规律;

  3. 尽量使用三种以上符号,如“字母+数字+特殊符号”。


AWS回应Elastic修改开源协议:创建“真正”开源的Elasticsearch分支

fanta2 发表了文章 • 0 个评论 • 90 次浏览 • 2021-02-04 10:11 • 来自相关话题

来源于公众号“程序猿DD”前几天刚给大家介绍过Elastic公司宣布:改变 Elasticsearch 和 Kibana 的开源协议,由 Apache 2.0 变更为 SSPL 与 Elastic License而在不久之后,云服务商Logz.io公司就对这一... ...查看全部

来源于公众号“程序猿DD”

前几天刚给大家介绍过Elastic公司宣布:改变 Elasticsearch 和 Kibana 的开源协议,由 Apache 2.0 变更为 SSPL 与 Elastic License

而在不久之后,云服务商Logz.io公司就对这一行为表达了自己的不满。

但是事情还没完,就像最近国内某郑姓女星的瓜层出不穷吃都吃不完一样,开源协议的宫斗剧也是一出接着一出。

当初Elastic公司改变协议的一大目的,就是针对自己的竞争对手AWS(Amazon Web Services——Amazon云服务)。为此Elastic公司的CEO,Shay Banon甚至曾经发文怒斥过AWS的一些行为。

如果说Logz.io公司还只算小打小闹,那么就在前几天,1月21号,AWS 官方做出回应,宣布将基于目前仍为开源状态的 Elasticsearch 和 Kibana( 7.10 版本)创建分支,开源许可证也会继续使用 Apache License 2.0。(和Logz.io公司发文中的意图不谋而合)

为了确保这个分支能够健康的持续发展使用,AWS 也宣称会负责后续的维护工作。

微信图片_20210203173028.png当然,和Logz.io公司发文中直接开怼Elastic不同,AWS更多的采用了隐晦的嘲讽模式(大公司的公关团队就是不一样!)。例如,AWS 声称自己将要创建的这个分支才是真正开源的 Elasticsearch,显然是在暗喻 Elastic 公司即将采用的双许可证方案(SSPL + Elastic License)算不是真正的开源,因为上述两个协议都不是 OSI (Open Source Initiative,开源促进会,批准开源协议的机构) 批准的开源许可证。微信图片_20210203173031.png

不过,AWS类似的事情并不是没有过。早在2019 年AWS就推出一个 Elasticsearch 的发行版——Open Distro for Elasticsearch,当时他们就对外标榜这款采用了 Apache License 2.0协议的产品,是 100% 开源。

AWS做这个申明的时候似乎忘了Amazon 靠着 Elastic 开发出来的东西赚到的钱就比他们自身赚到的还要多,因为这些内容可以跟 Amazon 的其他产品结合得更紧密,让别人使用更方便。

也为了这个Open Distro for Elasticsearch,Elastic 就在当年在加州联邦法院起诉Amazon 侵犯了自己的商标,一次次的矛盾升级之后最终才导致了Elastic痛下决心,进行开源协议改变。

不知道这一次,之前习惯了白嫖的AWS,是否能做出一个更好的开源Elasticsearch,让我们拭目以待!


开源模式反击之后,白嫖服务商竟然大叫“好自为之!”

徐凤年 发表了文章 • 0 个评论 • 90 次浏览 • 2021-02-04 10:11 • 来自相关话题

来源于公众号-程序猿DD还记得刚给大家介绍过Elastic宣布将改变 Elasticsearch 和 Kibana 的开源协议,由 Apache 2.0 变更为 SSPL 与 Elastic License。这一举动自然引起一些用惯了白嫖的云服务商的不满,这不... ...查看全部

来源于公众号-程序猿DD

还记得刚给大家介绍过Elastic宣布将改变 Elasticsearch 和 Kibana 的开源协议,由 Apache 2.0 变更为 SSPL 与 Elastic License。

这一举动自然引起一些用惯了白嫖的云服务商的不满,这不Logz.io公司官网就发布了一篇,简单总结就是:Elastic,你不讲武德!

微信图片_20210203173353.png

Logz.io公司描述到,Elastic的举动,已经在开源社区引起了轩然大波,无数依赖于Elasticsearch的组织都开始混乱无比。(潜台词:用惯了别人的东西一下子没得用了不知道该咋办)

而Logz.io声称已经联系了很多类似的组织,这些组织的共同点,就是认为Elasticsearch和Kibana应该保持开源而不是使用SSPL。Logz.io正在和这些组织商量一起打造一个真正的开源的Elasticsearch和Kibana版本。

所谓的真正开源,是Logz.io似乎准备自己搭建一个永远用Apache 2.0协议的Elasticsearch和Kibana项目,而维护整个项目的将是他们与多个志同道合的组织。(潜台词:以后没有白嫖的东西了,不自己做还能怎么办呢)

Logz.io公司同时还重申了自己公司的立场:

作为一个客户至上的组织,Logz.io公司最关注的是客户和社区用户的成功。Logz.io公司致力于用最好的平台来支持社区,以满足社区成员的可观察性需求。Logz.io公司将继续致力于在未来支持Kibana和Elasticsearch,并为客户提供最好的观测平台。

这里稍微介绍下,Logz.io公司主要基于AI的日志分析平台致力于帮助用户公司跟踪网站、应用及软件的情况,以避免发生代价高昂的停机故障。这些基本都依赖于Elasticsearch、Logstash和Kibana(ELK)堆栈的云服务分析日志。 所以说,Elastic的这次改变对他们是毁灭性的打击。

说够了远大前景,自然要吐槽下不满,文中,Logz.io公司对于Elastic团队的不满溢于言表:

Logz.io公司自从2014年来一直很敬佩Elastic,钦佩他们的公司文化、领导及业务(潜台词:先夸夸你再摔你),但是在最近几年,Elastic对于开源项目的投入已经江郎才尽,所有的心思都花在了商业上。同时认为Elastic决定关闭源代码以阻止竞争是一种背叛,背叛了他们的初衷:

微信图片_20210203173359.png

同时Logz.io公司认为一家价值数十亿美元的公司试图残酷地阻止竞争迫使社区用户为Elasticsearch付费,是不讲武德的!(潜台词:你家大业大,你给我白嫖下咋的了,你就应该继续免费,然后再战胜我们这些白嫖的人,这才是厉害啊)

最后,Logz.io公司相信,在Apache2下合作提供Elasticsearch和Kibana开源,对Logz.io公司的客户来说是正确的。对于任何依赖这些开源项目的人来说,这是正确的做法。最重要的是,Logz.io公司认为这对开源软件的未来是正确的。(潜台词:白嫖用户来关心开源软件的未来了!)


Spring Initializr中生成的mvnw是干吗的?

王叫兽 发表了文章 • 0 个评论 • 50 次浏览 • 2021-02-04 10:11 • 来自相关话题

来源于公众号-程序猿DD当我们使用Spring Initializr来创建Spring Boot工程的时候,有没有发现在工程根目录下有两个名为mvnw的文件:从命名、图标、扩展名来猜测,这两个文件的作用应该是一样的,只是cmd文件应该是用在windows下跑的... ...查看全部

来源于公众号-程序猿DD

当我们使用Spring Initializr来创建Spring Boot工程的时候,有没有发现在工程根目录下有两个名为mvnw的文件:

微信图片_20210203173520.jpg

从命名、图标、扩展名来猜测,这两个文件的作用应该是一样的,只是cmd文件应该是用在windows下跑的,而另外一个则是用于linux环境下跑的。

那么这个文件到底是用来做什么呢?下面我们一起尝试了解一下:

第一步:打开读一下

微信图片_20210203173526-1024x1531.png

因为内容较多,我这里就不放出来了。内容也非常易懂,只要你了解shell和maven,就能知道这个脚本主要做这几件事:

  1. 检测你是否有安装Maven,如果没有,就自动下载一个(这样才能完成后续的构建任务)

  2. 检查你是否有安装Java或者配置是否正确,这个无法自己完成,如果报错了,就要自己处理一下,比如JAVA_HOME没有,那就自己配置下。

  3. 检查否存在版本不兼容的情况,如果不兼容他会下载合适的版本来帮助你完成构建

更多检查的细节可以自行打开查看和学习

第二步:执行验证下

执行命令:mvnw install

微信图片_20210203173531.png等待构建完成,我们再看看:微信图片_20210203173534.png完美!轻松简单的完成了一个Spring Boot项目的构建!

拒绝白嫖!开源模式的反击:向不要脸的云服务商收费!

王叫兽 发表了文章 • 0 个评论 • 73 次浏览 • 2021-02-04 10:11 • 来自相关话题

年底将至,又到了大多数打工人开始编写年终小结的时候,但是总有那么一群人,平时碌碌无为,一等到年底,就到处打听到处收集各种成效数字,然后各种不要脸的洋洋洒洒的写在自己的年终小结里,仿佛那些完全没参与过的项目都是他一手打造的,彷佛那些别人辛苦一年才做出的成绩理应给... ...查看全部

年底将至,又到了大多数打工人开始编写年终小结的时候,但是总有那么一群人,平时碌碌无为,一等到年底,就到处打听到处收集各种成效数字,然后各种不要脸的洋洋洒洒的写在自己的年终小结里,仿佛那些完全没参与过的项目都是他一手打造的,彷佛那些别人辛苦一年才做出的成绩理应给他一样。

遇到这种人,气不气?

其实这种人不在少数,也正是有这样的人,才会有拿来主义,才会有做事毫无底线的云服务商,才导致了开源商业模式一再萎靡。

当然,老实人并不代表着一定要被欺负!就在1月15号,Elastic 公司 官方宣布:改变 Elasticsearch 和 Kibana 的开源协议,由 Apache 2.0 变更为 SSPL 与 Elastic License。

这次变更的主要针对目的,就是那些毫无底线的云服务商!

微信图片_20210203172125 (1).jpgElastic 公司 的CEO Shay Banon在他的博文中解释到:

虽然,从Apache 2.0 变更为 SSPL 与 Elastic License会改变一部分源代码,但是对于绝大多数的使用免费版本的用户及Elastic 公司的云客户以及自主管理软件客户也不会受到影响。唯一会受影响的,就是云服务商。

SSPL 允许用户以自由且不受限制的方式使用并修改代码成果,但是SSPL也有自己的要求:那就是如果将产品以作为一种服务进行交付,那么必须同时公开发布所有关于修改及 SSPL 之下管理层的源代码。

由此将限制云服务商在不对项目做出任何贡献的前提下,发布云服务商自己的 Elasticsearch 与 Kibana 服务,从而达到保护Elastic 公司的权益,亦可以让公司在开发免费产品方面持续投入的热情和资源,避免恶性循环。

微信图片_20210203172149.png

对于为什么会这么做,Shay Banon也给出了自己的解释:

长久以来,云服务商不断地肆意的将免费的开源软件集成到自己的云产品中,同时将其作为自己的云服务解决方案给予客户使用,俗称白嫖~造成了许多客户越来越多的放弃这些开源厂商的付费版本,直接断绝了开源厂商的经济来源!

早在Elastic之前,就有不少开源公司进行了变更:

Redis、MongDB、OpenCV、Google,Elastic绝不会是最后一个。

此次Elastic主要是借鉴了MongoDB的类似经验。

微信图片_20210203172152.png早在2018 年 10 月,MongoDB 就已经宣布将开源协议从 GNU AGPLv3切换到 SSPL,无论当时如何引起部分用户的不满,MongoDB 至少目前还很健康的继续经营,股价也从 2018 年的不足 100 美元 / 股涨到现在的 361 美元 / 股。可以说是开源公司学习的楷模。微信图片_20210203172155.jpg

SSPL 就是由 MongoDB 最初创建的可提供源代码的许可证,旨在体现开放源码理想的许可证,允许自由和不受限制地使用,修改和重新分发。

SSPL最简单也是最核心的一点就是前文提过的:如果将产品以作为一种服务进行交付,那么必须同时公开发布所有关于修改及 SSPL 之下管理层的源代码。

SSPL 是基于GPLv3 的 copyleft 许可证。并没有经过 OSI(Open Source Initiative,开源促进会,批准开源协议的机构) 批准,因此官方还特意声明:为了避免混淆,我们暂时不将两个产品称为开源,而使用“免费和开放” 进行描述。

有时候甚至会觉得,SSPL纯粹就是被那些习惯了白嫖的云服务商逼出来的产物,就像当每个人做事都只顾着看别人的成效数字,又有几个人能真正做好事呢?


开源商业模式正在被云服务商杀死!

柠檬^ 发表了文章 • 0 个评论 • 52 次浏览 • 2021-02-03 17:20 • 来自相关话题

对程序员圈子来说,Mapbox是一家专注于地图绘制的卓越软件公司。从Mapbox GL JS(他们的2D地图渲染器)到自动驾驶和导航库,再到增强现实、3D可视化,甚至视频游戏技术,Mapbox在这一领域做到非常棒,其创新成果占有巨大的市场份额。而且这些内容都是... ...查看全部

对程序员圈子来说,Mapbox是一家专注于地图绘制的卓越软件公司。从Mapbox GL JS(他们的2D地图渲染器)到自动驾驶和导航库,再到增强现实、3D可视化,甚至视频游戏技术,Mapbox在这一领域做到非常棒,其创新成果占有巨大的市场份额。而且这些内容都是开源的,也是让众多程序员喜欢他们的原因之一。

但是昨天看到了一个让我震惊的新闻:最新版本的Mapbox GL JS将不再是开源的!!!

作为个人来说,我并非是一个完美的热衷于开源的粉丝,因为我知道,创建和维护开源代码是多么一件吃力不讨好的事情,真的是非常累人,所以我一直很尊敬那些愿意开源的程序员,并且哪怕是开源,哪怕是对方过去已经丢弃不用的想法,我都觉得自己没有权力肆意使用对方的想法和知识产物。

但是同样的,直到昨天看到那个新闻之前,我仍然对商业开源软件抱着些许的客观、浪漫、自欺欺人的想法。在我的想法中,这是一个在当下重名利的世界中,保持着那颗开源的心,一直以开源做为自己的商业模式,持续走下去的童话故事,而Mapbox就是故事的主角,

去年的时候我也写过关于Mapbox商业模式的文章,就是他即提供了一种免费开源的版本,也提供了一种收费的版本,这些收费版本当然有一些独到的免费版本没有的功能。 听起来,有点像王者荣耀中有皮肤和没皮肤的概念。

如果对开源的商业模式有进一步了解兴趣的,建议可以看下Joseph Jacks的博文,链接地址如下:https://medium.com/open-consensus/2-open-core-definition-examples-tradeoffs-e4d0c044da7c

在最初的时候,没有人相信这种模式管用,但是随后发生的一切让人大跌眼睛,像Elastic、D2iQ(以前的Mesosphere)、MongoDB和Cloudera这样的几十家公司,都通过这种过往没出现过的方式,成功赚取了数十亿美元的投资。当然和现在相比,那个时候他们开放的开源版本可是开放好多。

直到今天,看了那个新闻之后,我们不由得感慨,开源模式即将死去!

那是什么让他从一时兴旺到如今的一命呜呼呢?

云服务商!

我们先回到Mapbox的例子,在Mapbox GL JS使用的案例中,Mapbox最早的决定是,开源其基于浏览器的地图渲染器的最早的两个版本(像我们熟知的Snap-Maps、纽约时报和CNN都用过)。自2014年首次发布以来,它在web开发人员中一直非常流行。一旦你知道你在找什么,你就会开始到处看到它。

微信图片_20210120152742.png

而对于我自己来说,当我的团队开始构建一个标记卫星图像的项目时,我才亲身体验了Mapbox GL JS的功能是有多么强大。使用Mapbox GL JS的功能,支持复杂几何图形的自由形式绘图,最终的成品是可以在地图上形成形状,也就是说是我的标记是被投影到地球上的一个真实位置,而不是简单的仅仅是悬浮在想象中的二维空间。这种效果让人感觉明显和直截了当,非常好用。

但事实上如果我不用Mapbox GL JS,从零开始设计就会非常非常困难。因为即使是用徒手画的简单形状也可以包含数千个单独的点。这样的话很快,我的屏幕上就会被数十万个顶点的形状填满,然后很显然,我的浏览器就会崩溃。而Mapbox GL JS是通过调用计算机上图形卡来帮助解决这个问题,如果不依靠Mapbox那几万小时的艰苦的工程工作,我们不可能在预算和时间有限的情况下完成该功能。Image for post

而这周Mapbox决定公布一个Mapbox GL JS的新版本,这个新版本不再开源瞬间震撼到了我!不仅仅是因为之前的V1版本是一个广受欢迎的开源版本,而是因为Mapbox作为一个开源代码的代名词给予我的那种崇高的敬意。在我的看法里,如果你要描述Mapbox是一家怎么样的公司而不提到开源,就像你和一个从未喝过的人谈到巧克力牛奶时不说这是一种液体一样!

Mapbox迄今为止,仍拥有超过800个开源项目,并在Github公共存储库活动方面一直名列全球前40名。并且Mapbox一直在给世界上知名度最高的开源软件贡献者提供各种工作机会,不仅仅是地图行业。

所以说,到底突然发生了什么?

其实,一切都源头还都是因为开源不再是一个在当下这个时代能站得住脚的商业模式!

Mapbox选择保持Mapbox GL JS的V2版本的专有权而不再开源就是一个强烈的信号。虽然这信号背后到底代表着什么还不是很清楚,但是已经让我咬牙切齿。。。

在我看来,这已经意味着我们要迎接一个时代的结束,这预示着代表着开源这种商业模式的寿命的终结!

其实我的潜意识里一直有着这个想法,早在Mapbox的新闻之前,但是Mapbox的新闻是真正为我心中猜想敲上实锤的那最后一击。

为了了解即使像Mapbox这样的公司也决定从开源转变的原因,我觉得可以先看下Mongo DB和Redis Labs这两个行业同行之前已经发生过的故事。

就在两年前,知名科技博主Ben Thompson写过一份文章,文章中阐述了一份总结关于AWS(Amazon Web Services——Amazon云服务), MongoDB和开源代码的经济回报。按他的说法就是:如果你提供了你的独家代码作为开源代码,并且让它变得流行起来,那么那些云服务商必然将用这些代码来为他们自己所用,为他们制造一些竞争性的服务,就好比用你制作的武器来攻击你一般,并且他们的心中没有丝毫歉意和犹豫,他们的眼中只有利益,对于这种行为,你的律师最后只会对你说一句无能为力,因为你曾经自己将这些内容开源了!

Ben在文中提到AWS推出了一项与MongoDB和Redis的付费产品直接竞争的对手服务,但也没有完全击败对手。事实上,自从那个时候起,MongoDB的股价从那时起已经上涨了275%,Redis在几个月前刚刚筹集了1亿美元,正式跨过了10亿美元的神奇估值门槛。

微信图片_20210120152751.png

但我想表述的更重要的不仅仅是Mongo和Redis在受到AWS的攻击后依旧蓬勃发展,而是他们是如何做到的?

这两家公司都以公司一贯的方式反击:一支知识产权的律师大军。

Redis采取了一种策略,在现有开源工具的更新版本中加入了一个有着严格限制性条件的commons条款,不过这让一些著名的开源代码的支持者非常不满:

微信图片_20210120152753.png

鉴于此,Redis后来用了另外一种方法,申请了一个完全新颖和独特的许可证,虽然这不会比commons条款更糟,但几乎可以肯定的是也不会更好。

另一家公司MongoDB呢?它也采取了俗称poison pill(毒丸) 的法律策略,在AWS推出竞争性的服务后不久,它就为自己的软件申请了一个新的、同样是虚构的许可证Server-Side Public License (SSPL)。

这些动作都是为了对抗云服务商的一系列举措。

更准确的说,他们的开源产品对任何有规模的公司都会起到使用时是否合规这个问题。

当然,这么做的代价就是Redis和Mongo从根本上减少了开源的开放性。从结果看,他们做的很好,虽然这是以牺牲了它们最初的理想为代价的,但毕竟活着是最重要的。

但是很多开源作者觉得自己被出卖了一样,我能理解他们的感受,但是我也理解Redis或MongoDB这么做是理性的生意行为。

回到Mapbox上,至少已经有一家云服务商公开的将Mapbox的代码复制并粘贴到他们的收费服务中: Azure,微软的云服务

去年,Azure发布了由Mapbox GL JS支持的地图样式,它是Azure地图服务的一个关键特性。为此,Mapbox甚至在他们公司的博客上写了一个声明。

虽然我们可以理解为Mapbox写这个声明是件好事,但我严重怀疑这是导致了Mapbox GL JS不再开源的开始。毕竟,在竞争无比激烈的公共云世界里,一旦一个云服务商开始提供服务,其他服务商肯定很快就照猫画虎一样开始提供类似服务。Mapbox终于发现自己的处境与MongoDB和Redis是如此的相似:它们在为那些万亿美元的科技巨头免费提供研发基础!

与Mongo和Redis不同,Mapbox最终还是抵抗了一些冲动。他们没有改变产品开源部分的基本许可证,而是彻底打破了这一局面。旧版本仍然是一个成熟且非常有用的版本,将保留其原始的许可证。同时Mapbox召集社区成员无限期地维护这个版本,我希望这会有用。

而新版本将保持一定程度的公开(例如代码都发布在Github上)。但是它不再是开源那样的了。对我来说,这感觉是一个更诚实的方法,而不是试图用一个没见过的、完全未经证实的许可证或一些“看似明白”的条款来穿针引线制造一种假象。

有些人可能会觉得这是一场悲剧,因为这意味着社区捐献可能会减少。诚然,尽管贡献者名单很长,但Mapbox的现任和前任员工还是贡献了最大的份额。但是这个项目已经吸引了一个庞大的、全球性的工程师群体,他们用它来建造东西,对它进行技术讲座。毫无疑问,昨天对于那些充满创作热情的用户来说的确是一个悲伤的日子。他们会继续过下去,但肯定有一种莫名的失落感。

至于这么做是否偏离了Mapbox最初的使命或公司文化?我想这条来自一位自公司成立以来一直在公司工作的现任员工的微博很好的总结了这一点:

微信图片_20210120152756.png

现实中很多事情都是很无奈的,毕竟我们要吃饭要生存下去。

很久以前我天真的以为围绕开源建立一家公司是很容易的,并且其他人都会很道德的使用这些开源的信息,但是现在我不再敢肯定这些。

我仍然相信开源是世界上一股强大的向善力量。我仍然认为,有的公司可以战略性地、认真地为开源做出贡献,不仅为自己的使命服务,也为集体利益服务。

但是,相对的,我再也不相信那些靠着风投存活下去的公司能够负责任地推行这种策略,将软件作为其价值主张的核心。我不再认为这是一个可行的模式,因为或快或慢,他们都会被他们的野心所吞噬,因为如果不这么做,他们最终只能在被自己的武器干掉和背叛最初的理念中间二选一。

昨天真是令人难过的一天。不仅仅因为Mapbox的宣布令人失望,而且就在昨天,我终于不得不向自己承认一点:

云服务商真的杀死了开源!

(来源于公众号:程序猿DD)


关于高阶JAVA枚举你不知道的事!

赵炳东 发表了文章 • 0 个评论 • 101 次浏览 • 2021-02-03 17:12 • 来自相关话题

JAVA枚举,比你想象中功能还要强大!我经常发现自己在Java中使用枚举来表示某个对象的一组值。在编译时确定类型可以具有什么值的能力是一种强大的能力,它为代码提供了结构和意义。当我第一次了解枚举时,当时我认为它们只是一个为常量命名的工具,可以很容易地被静态常量... ...查看全部

微信截图_20210203171135.png

JAVA枚举,比你想象中功能还要强大!

我经常发现自己在Java中使用枚举来表示某个对象的一组值。

在编译时确定类型可以具有什么值的能力是一种强大的能力,它为代码提供了结构和意义。

当我第一次了解枚举时,当时我认为它们只是一个为常量命名的工具,可以很容易地被静态常量字符串ENUM_VAL_NAME所取代。

后来我发现我错了。事实证明,Java枚举具有相当高级的特性,可以使代码干净、不易出错,功能强大。

让我们一起来看看Java中的一些高级枚举特性,以及如何利用这些特性使代码更简单、更可读。

枚举是类!

在Java中,枚举是Object的一个子类。让我们看看所有枚举的基类,Enum<E>(为简洁起见进行了修改)。

public abstract class Enum<E extends Enum<E>>
    implements Constable, Comparable<E>, Serializable {
  private final String name;
  
  public final String name() {
      return name;
  }
  
  private final int ordinal;
  
  public final int ordinal() {
      return ordinal;
  }
  
  protected Enum(String name, int ordinal) {
      this.name = name;
      this.ordinal = ordinal;
  }
  
  public String toString() {
      return name;
  }
  
  public final boolean equals(Object other) {
      return this==other;
  }
  
  public final int hashCode() {
      return super.hashCode();
  }
  
  public final int compareTo(E o) {
      Enum<?> other = (Enum<?>)o;
      Enum<E> self = this;
      if (self.getClass() != other.getClass() && // optimization           self.getDeclaringClass() != other.getDeclaringClass())
          throw new ClassCastException();
      return self.ordinal - other.ordinal;
  }
}

我们可以看到,这基本上只是一个常规的抽象类,有两个字段,name和ordinal。

所以说枚举都是类,它们具有常规类的许多特性。

我们能够为枚举提供实例方法、构造函数和字段。我们可以重写toString(),但不能重写hashCode()或equals(Object other)。

接下来我们看下我们的枚举示例,Operation

enum Operation {
    ADD,
    SUBTRACT,
    MULTIPLY
  }

这个枚举表示一个Operation可以对两个值执行,并将生成一个结果。关于如何实现此功能,您最初的想法可能是使用switch语句,如下所示:

 public int apply(Operation operation, int arg1, int arg2) {
    switch(operation) {
      case ADD:
        return arg1 + arg2;
      case SUBTRACT:
        return arg1 - arg2;
      case MULTIPLY:
        return arg1 * arg2;
      default:
        throw new UnsupportedOperationException();
  }
}

当然,这样子会有一些问题。

第一个问题是,如果我们将一个新operation添加到我们的Operation中,编译器不会通知我们这个开关不能正确处理新操作。

更糟糕的是,如果一个懒惰的开发人员在另一个类中复制或重新编写这些代码,我们可能无法更新它。

第二个问题是默认情况default,每段程序里面都是必需的,尽管我们知道在正确的代码里它永远不会发生。

这是因为Java编译器知道上面的第一个问题,并且希望确保我们能够处理在不知情的情况下向Operation中添加了新枚举。

还好,Java8用函数式编程为我们提供了一个干净的解决方案。

函数枚举实现

因为枚举是类,所以我们可以创建一个枚举字段来保存执行操作的函数。

但是在我们找到解决方案之前,让我们先来看看一些重构。

首先,让我们把开关放在enum类中。

 enum Operation {
  ADD,
  SUBTRACT,
  MULTIPLY;
  
  public static int apply(Operation operation, int arg1, int arg2) {
    switch(operation) {
      case ADD:
        return arg1 + arg2;
      case SUBTRACT:
        return arg1 - arg2;
      case MULTIPLY:
        return arg1 * arg2;
      default:
        throw new UnsupportedOperationException();
    }
  }
}

我们可以这样做:Operation.apply(Operation.ADD, 2, 3);

因为我们现在从Operation中调用方法,所以我们可以将其更改为实例方法并使用this,而不是用Operation.apply()来实现,如下所示:

public int apply(int arg1, int arg2) {
  switch(this) {
    case ADD:
      return arg1 + arg2;
    case SUBTRACT:
      return arg1 - arg2;
    case MULTIPLY:
      return arg1 * arg2;
    default:
      throw new UnsupportedOperationException();
  }
}

像这样使用:Operation.ADD.apply(2, 3);

看起来变好了。现在让我们更进一步,通过使用函数式编程完全消除switch语句。

enum Operation {
              ADD((x, y) -> x + y),
              SUBTRACT((x, y) -> x - y),
              MULTIPLY((x, y) -> x * y);
  
              Operation(BiFunction<Integer, Integer, Integer> operation) {
                      this.operation = operation;
              }
  
              private final BiFunction<Integer, Integer, Integer> operation;
  
              public int apply(int x, int y) {
                      return operation.apply(x, y);
              }
  
  }

这里我做的是:

  • 添加了一个字段 BiFunction<Integer, Integer, Integer> operation

  • 用BiFunction创建了用于Operation的构造函数。

  • 调用枚举定义中的构造函数,并用lambda指定BiFunction<Integer, Integer, Integer>。

这个java.util.function.BiFunction operation字段是对采用两个参数的函数(方法)的引用。

在我们的例子中,两个参数都是int,返回值也是int。不幸的是,Java参数化类型不支持原语,所以我们必须使用Integer。

因为BiFunction是用@functioninterface注释的,所以我们可以使用Lambda表示法定义一个。

因为我们的函数接受两个参数,所以我们可以使用(x,y)来指定它们。

然后我们定义了一个单行方法,它使用 ->x+y 返回一个值。这相当于下面的方法,只是更简洁而已。

  class Adder implements BiFunction<Integer, Integer, Integer> {
          @Override           public Integer apply(Integer x, Integer y) {
                  return x + y;
    }
  }

我们的新Operation实现采用相同的方式:Operation.ADD.apply(2, 3);.

但是,这种实现更好,因为编译器会告诉我们何时添加了新Operation,这要求我们更新函数。如果没有这一点,如果我们在添加新Operation时还不记得更新switch语句,就有可能得到UnsupportedOperationException()。

关键要点

  • Enum枚举是Enum的扩展类。

  • Enum枚举可以有字段、构造函数和实例方法。

  • Enum枚举字段可以存储函数。与lambda配合使用,可以创建干净、安全的特定于枚举的函数实现,并在编译时强制执行它们(而不是使用switch)。

下面是这个示例的GitHub地址。(https://github.com/alex-power/java-enum-example)

本文参考:https://medium.com/javarevisited/advanced-java-enum-features-you-need-to-know-b516a191c7e2

(来源于公众号:程序猿DD)


微信第 1 行代码曝光!

徐凤年 发表了文章 • 0 个评论 • 81 次浏览 • 2020-11-30 10:16 • 来自相关话题

来源:微博编辑:卫民【导读】腾讯官方微博今日凌晨发布了微信10年前在微信后台第一天提交的代码,这个在今天看来略显简陋的代码,最终孕育了庞大的微信。张小龙这个「产品经理」,也用十年时间,打磨出了一款「国民级」应用。10年前的今天,你在干什么? 你可能在... ...查看全部
来源:微博
编辑:卫民
【导读】腾讯官方微博今日凌晨发布了微信10年前在微信后台第一天提交的代码,这个在今天看来略显简陋的代码,最终孕育了庞大的微信。张小龙这个「产品经理」,也用十年时间,打磨出了一款「国民级」应用。

10年前的今天,你在干什么?
 
你可能在吃饭、在睡觉、在QQ上聊天,但你绝对不可能是在刷微信朋友圈。
 
因为那时候的微信,才刚刚诞生于程序员敲写的代码中。
 
2010年11月23日的凌晨,广州,一群年轻人在小黑屋里敲下了一行行代码。
 
这是微信后台第一天提交的代码。
 
从此,人们的沟通方式变了。
 
如今,微信已经有超过12亿的用户,是一款真正的「国民级」应用。
 
微信的功能也越来越丰富,朋友圈、公众号、小游戏、小程序、微信红包、视频号……
 
微信已经成为一个庞大的生态,而这一切的开始,就是那一行行在今天看来略显简陋的代码。
 
不得不说,程序员们,再一次改变了世界。

1.png

张小龙的一封邮件和微信的诞生

「想到那封邮件,我时不时会觉得有点后怕,如果那个晚上我没有发这封邮件,而是跑去打桌球去了,可能就没有微信这个产品了,或者是公司另一个团队做的另一个微信。」
 
在去年的微信公开课上,张小龙首次公开了微信诞生的真相。
 
在某个深夜,张小龙写了一封邮件给Pony,开启了微信这个项目。
 
而在此前,坊间流传着更为「传奇」的故事:张小龙因技术难题,心情烦闷,遂前往北京龙泉寺小住,其间得一扫地高僧指点,才有了微信的诞生。

2.png

这个故事当然只是人们的臆测和媒体的加工,世上若有扫地僧,那这个扫地僧就是张小龙自己。
 
在做微信之前,张小龙负责腾讯的QQ邮箱项目,并把QQ邮箱做到了国内第一名,而且在邮箱里面又做了很多尝试,包括漂流瓶、阅读空间等。
 
也正是在QQ邮箱的阅读空间里,张小龙看到了一个让叫做kik的产品,这让他产生了灵感。
 
Kik在当时是一款刚上线,基于手机通讯录的的社交软件,15天内吸引了超100万用户。它可以实现免费短信聊天,但不能发照片也不能发文件,是一款非常简单的即时通信软件。
 
张小龙连夜给马化腾写了封邮件,建议做一个类似kik的产品,马化腾当即同意。

3.png

不久之后,第一版的微信,就这样诞生了。
 
虽然说龙泉寺的故事有点扯,但是张小龙也不否认伟大产品的诞生确实是需要灵感的,并不是死想就可以想出来。他表示:
 
「我发现很多想法是突如其来的,或者说,是上帝编好程序,在合适的时候放到你的脑袋中的。」

4.png

不断迭代更新,从一行代码到12亿用户

但是刚刚上线的微信,并没有带来太大的反响。
 
因为这个时候的微信,更像是一种短信的替代品,对用户并没有太大的吸引力。
 
转变发生在一次功能的更新之后。2011年5月,微信更新了语音聊天功能,用户得到了井喷式增长。

5.png

张小龙继续带领团队,开发出「摇一摇」和「漂流瓶」功能,持续的迭代让人惊喜连连,用户使用软件的兴趣被大大提升。
 
2011年8月,微信添加了「查看附近的人」的陌生人交友功能,再次迎来爆发式增长。日增用户数一举达到了10万以上,用户达到1500万 ,到2011年底,微信用户已超过5000万。
 
2012年4月,微信第一次有了「朋友圈」,人们开始习惯在这里记录生活,朋友圈的出现极大的改变了人们交友的方式。

6.png

2012年7月,微信上线了「视频通话」功能,使得人们在语音和文字之外,开启了一种远程「面对面」的聊天方式。
 image.png

2012年,微信公众平台也上线,「订阅」喜欢的帐号开始成为一种流行,自媒体开始真正兴起,这对媒体行业和中国社会产生了巨大影响。

image.png

2013年8月,微信添加了表情商店和游戏中心,扫一扫功能全新升级,可以扫街景、扫条码、扫二维码、扫单词翻译、扫封面。
 
2014年3月, 微信开放了微信支付功能,并公布了以微信支付为重要支撑的「微信智慧生活」全行业解决方案。
 
2015年1月,微信新版增加了「附件栏发微信红包」「更换手机时,自定义表情不会丢失」「可以搜索朋友圈的内容和附近的餐馆」三大功能。
 
2017年1月,微信小程序低调上线,再次引领微信生态的重大变革。
 
2017年12月,微信更新的6.6.1版本突然开放了小游戏,微信启动页面还重点推荐了小游戏「跳一跳」,风靡一时。
 
2018年,微信「时刻视频」上线,可以用「时刻」记录眼前的世界。

image.png

2020年,在短视频的风口下,微信又增加了「视频号」的功能,目前发展势头迅猛。
 
微信背后,最成功的「产品经理」张小龙

在腾讯内部,张小龙有「地成佛」的称号。
 
这个称呼源于他在微信「跳一跳」小游戏上的「无敌」。
 
张小龙在微信小游戏跳一跳中达到的最高分数是 6000 分,而在这个游戏中分数超过 3000 分的,只有 20 个人。
 
这或许可以看出张小龙在一件事情上的专注和不断尝试。
 
和一些程序员出身的管理者不同,张小龙在注重技术的同时更注重用户体验。
 
而微信之所以能够一步步的发展到今天,也与张小龙从用户体验的角度出发,去不断打磨一款舒服的产品有关。
 
「很多产品不把自己当产品看待,不把用户当用户看待。而微信,做到了这两点。」张小龙曾在公开课上表示。

image.png

如果说腾讯的前半场是QQ撑下来的,那么下半场无疑是微信让腾讯再次焕发了活力。
 
如今,微信稳坐中国乃至全球社交软件头把交椅,丰富实用的功能深刻的影响了10多亿人生活的方方面面。
 

而这一切,皆源于10年前的那一行行简陋的代码,以及敲下代码的程序员们。


老旧系统重构技巧,轻松搞定遗留代码

王叫兽 发表了文章 • 0 个评论 • 95 次浏览 • 2020-11-30 10:03 • 来自相关话题

前几天偶然看到一位网友发的内容,说是老系统改了一行代码就崩溃了,着实令人头秃。越是成功的公司,越是有大堆的老系统和无法统计的遗留代码,尤其是基础服务相关的代码,那简直是按下葫芦浮起瓢的现实版本。创业公司倒是好一点,没有历史包袱。我们也经常重构老旧代码,不为别的... ...查看全部

摄图网_500719153_wx_商务办公绩效分析(非企业商用).jpg

前几天偶然看到一位网友发的内容,说是老系统改了一行代码就崩溃了,着实令人头秃。越是成功的公司,越是有大堆的老系统和无法统计的遗留代码,尤其是基础服务相关的代码,那简直是按下葫芦浮起瓢的现实版本。创业公司倒是好一点,没有历史包袱。我们也经常重构老旧代码,不为别的,就是怕放太久发霉。恰好最近也在做系统重构,总结下我们在做的事情和一些技巧。


代码也会发霉



会发霉的不只是食物,代码也会。我们通常称为腐化。腐化的过程每天都在发生,一个紧急需求,一个新同事加入,一个变态的问题修复,一个共建项目,等等。腐化,是永远无法避免的,就像宇宙的熵增不可逆一样。面对腐化,架构师往往会加上一个防腐层。如果你的系统还没有防腐层,赶紧考虑考虑。即便有防腐层,也招架不住岁月的摧残,就像头上那日渐稀少的秀发,这就是命啊。

所以,我们需要重构。逆熵增需要做大量的功,要对混乱的代码重新梳理,使其恢复条理清晰、架构分明的优良状态。


梳理,还是梳理



重构前花大量时间对历史逻辑做梳理,而且要细致。古人曰“工欲善其事,必先利其器”。梳理好的逻辑就是重构的指路明灯。哪些要丢弃,哪些要优化,哪些要重构,哪些要产品重新定,哪些是风险点,在梳理好后就基本明了了。梳理带来的不只是逻辑的浮现,可能还有架构的方向。通过梳理,能够明确发现业务逻辑,甚至可以定义出新的领域模型、值、事件等。想想银河纪元时代,拿着银河系实时星图作战,就知道梳理有多重要了。


回放,对比变化



重构之后,测试要全面覆盖。这时候,回放就非常重要了。阿里也开源了一个回放工具 jvm-sandbox-repeater。GitHub 地址https://github.com/alibaba/jvm-sandbox-repeater。通过回放,可以在预发环境 debug 线上问题,可以看到线上真实流量在预发环境的实际表现。通过对比,可以发现重构后哪些地方和之前不一样了,尤其是页面渲染和持久化的数据。

回放做好以后,还可以作为日常发布的快速验证。只要本次回放和上次正常回放差异不大,基本上风险就已经很小了。


架构,以终为始



既然做重构了,架构方面就要好好设计。尽量摒弃错综复杂的历史逻辑,设计新的架构方案。以提高研发效率、降低维护成本为最终目标,所有的重构设计都围绕着这个目标展开。没有什么是不能改的,如果不能,那就加两个更牛逼的程序员。如果重构后还保留一坨屎一样的遗留代码,真不知道重构的意义是什么。重构就是要以终为始,在新的架构设计中,让遗留代码重新投胎以获得新的生命。


改善,代码重构



优秀的程序员是需要不定期对已有代码做或多或少的重构的。在《重构 改善既有代码的设计》一书中,作者已经给了很多重构的具体方法。重复代码抽出、过长函数拆分、模型重新设计、封装字段、封装集合、以State/Strategy取代类型码、方法移动位置等诸多技巧,这里就不展开了。我觉得每个程序员都应该好好学习下这本书,然后深入实践下代码级重构。正如书评所说“虽不应翻着重构手册干活,但需对本书中提到的70多个重构方法成竹在胸”。


速度,速战速决



遗留代码很多已经像网贷一样了,越陷越深。投入资源做重构所获得的回报,实际上比继续维护老代码高的多。重构的过程要快,过程中日常需求尽量暂停。重构的工作量很大,但是对速度要求也很高。如果一边重构,一边线上还在做需求变更,很可能陷入困境,甚至在重构后丢失线上逻辑。梳理做好了,回放做好了,程序员就可以按照计划快速重构,多上几个人,确保快速完成。



心态,胆大心细



前面的工作都做好了,那接下来就是干了。

放心大胆地干,不要怂。这段代码看不懂怎么办,改!看回放。这段代码又臭又硬怎么办,改!看回放。

改的时候,也要心细一点,好好理解下原有的业务逻辑。在战略上藐视敌人,也要在战术上重视敌人。做好 code review,让了解的人一起看改动,或者团队成员一起把把关。


本文转自“程序之心”,原文地址https://mp.weixin.qq.com/s/AwoJOLclWhvvTp-KuzS4uA


融云获得数亿元 D 轮融资 海外基金 eWTP 与深创投联合领投

梅川酷子 发表了文章 • 0 个评论 • 101 次浏览 • 2020-11-09 16:32 • 来自相关话题

近日,全球互联网通信云领导厂商融云正式宣布,完成数亿人民币 D 轮融资。本轮融资由 eWTP 中东北非区域基金和深创投集团联合领投。融云表示,此次融资主要用于持续打造全球云通信能力,具体表现在两个方面,一是持续提升图、文、音、视“全”通信能力,重点加大实时音视... ...查看全部

近日,全球互联网通信云领导厂商融云正式宣布,完成数亿人民币 D 轮融资。本轮融资由 eWTP 中东北非区域基金深创投集团联合领投。融云表示,此次融资主要用于持续打造全球云通信能力,具体表现在两个方面,一是持续提升图、文、音、视“全”通信能力,重点加大实时音视频产品的研发投入;二是全球通信网络的持续研发优化,同时,进一步扩展全球市场,尤其对“一带一路”的国家和政府,输出通信服务的整体解决方案,以 PaaS 能力+应用层产品为国家级项目提供支撑,而在发达国家将考虑开设分支机构,满足海外开发者 PaaS 能力的需要。

1.png 两大投资机构首次投资融云

强烈看好通信云赛道

本轮领投方 eWTP 中东北非区域基金创始合伙人李晋吉表示,“我们强烈看好云通信赛道。投资融云,不仅因为他们坚实的业绩,更希望与融云能够达成更深层次的业务合作,借助基金平台资源全面赋能融云,以更深度的运营支持融云海外布局,帮助融云持续全球化。”

据了解,本轮联合领投方深创投公司在投资企业数量、投资企业上市数量上,均居国内创投行业第一位,被投企业分别在全球 16 个资本市场上市。本轮是深创投首次投资融云,对此,深创投执行总经理刘敏表示,投资融云主要基于四个方面的考虑:一是融云在 IM 领域市场的行业龙头地位,且音视频技术基础扎实,IM+音视频具备双重实力;二是融云自身的营收增长速度超过预期;三是疫情的爆发为云通信产业创造了空前的发展红利期;四是融云拥有资深且专业的云通信领域创业团队。因此他认为,融云作为为云通信领域提供基础能力的公司,具备极强的发展潜力和发展空间,未来有望成为中国通信云领域的第一厂商。

目前,融云已经位列全球互联网通信云头部阵营。据艾瑞报告显示,融云连续多年在 IM 领域市场占有率第一,实时音视频位居第一阵营;在技术层面,融云是行业内唯一一家可以提供“IM 即时通讯+RTC 实时音视频+Push 推送整体通信解决方案的服务商,可以为客户提供“全”通信服务;在客户层面,全面覆盖互联网、政企、智能硬件及海外市场;并且,融云还自建了全球通信网络,成为为数不多的拥有海外数据中心的通信云服务商。 

▲  融云以“一套 SDK 解决所有通信场景”

3.png

融云重点发力互联网、政企及海外市场

目前,融云重点在三个市场发力:持续夯实国内互联网市场、深耕政企市场以及进一步拓展海外市场

在互联网市场,融云拥有深厚的客户积累,超过 25 万开发者在使用融云,使融云成为一家隐藏在 30 万款 App 背后的通信云巨头。因海量客户积累,融云产品可快速迭代,且拥有良好的技术和服务口碑。随着 5G 商用落地,越来越多客户有 IM 即时通讯+实时音视频的“1+1”需求,因此,也助推融云实时音视频拥有在互联网市场后发先至的优势,目前融云实时音视频平台付费用户已超千家,测试用户达数万家。本轮融资后,在技术侧还将持续加强实时音视频产品的研发投入,持续夯实互联网市场。 

在政企市场,融云将持续加强与 SI、ISV 的深入合作,为中国的政企市场赋能通信基础能力。目前,融云已经全面支持国产化芯片、操作系统、中间件及数据库组件的组合,未来还将持续支持国产化进程,深耕政企市场。

在海外市场,融云 2016 年便完成了海外布局,跟随中国企业出海,服务中国开发者。目前,融云可对“一带一路”的国家和政府,输出通信服务的整体解决方案,以 PaaS 能力+应用层产品为国家级通信项目提供支撑;未来2至3年,在发达国家增加对海外本地化开发者的 PaaS 服务支持,进一步扩展全球市场。

融云创立于 2014 年,核心团队来自中国移动的飞信团队,6 年来只专注于通信云赛道。疫情因素,使全球互联网通信云赛道明显由窄变宽,2020 年融云在互联网、政企及海外市场这三大领域同时获得高速增长,用户使用量成倍数增加,提前完成全年营收,实现盈利目标

目前,融云服务的客户包括:中国工商银行、中国移动、四川航空、CCTV 微视、中联重科、新东方、编程猫、核桃编程、乐学高考、陆金所、融创地产、IDG、华兴资本、汽车之家、易车、得到 APP、荔枝、哈啰出行、来疯直播、斗米、土巴兔、Opera、StarMaker、Lispon、EleLive、MiniJoy、Castbox 等。

3.png ▲  融云服务超过 30 万款 APP


据权威数据研究机构分析,预计 2023 年全球互联网通信云 PaaS 市场规模将达百亿美元,中国市场在全球的占有率将超过 50%,融云作为全球互联网通信云领域头部厂商,未来在通信云计算市场仍有长足的价值增长空间。

友情链接