java

企业web应用技术讨论 基于兴趣和职业发展的考虑，我参加了上次关于“增量配网产品”架构的讨论会议，对公司现有的产品，人员，技术储备有了一定的了解。 会上对未来几年公司使用的技术栈有了指导性的意见，但候选项只有项目中已经使用的几个非常成熟的技术，个人认为欠缺广度和深度。 仅有限的几个同事参与，意味着可能公司有人掌握了某项技术，但没有成为一个候选项。 除了手边会用的工具， 也应该到市面上找更合适的工具。 一定的技术预研和储备是非常必要的 故写了这篇文章，抛出我的观察和思考，然后看看“沉默的大多数"中有没有志同道合的人，可以将一些更先进(合适)的技术引入公司业务， 助力公司发展。 由于我们讨论的是企业web应用，所以需要关心的问题大概有下面几类，我们依次讨论。 web， 即前端 一些传统的企业开发不重视前端，觉得能用就行，分工上也没有专门的前端工程师，而是由后端工程师一把梭。 但前端的工作量并不小，开发维护成本很高，且易用性美观度等也大大影响用户对软件的整体印象。 如果有多端显示，小程序等需求，则难度和成本更是直线上升。 传统的 js 和 jquery 应用缺乏模块管理，依赖管理，组件化支持等关键特性， 为了解决这些问题，前端的生态发展很快，工程化和模块化水平已经不输后端，出现了 angular, reactjs, vue, svelet 等优秀的 mvvm 框架， 以及 typescript 这样的强类型编译语言，解决了前端大代码量下的开发效率问题。 对于需要 seo 的应用， 纯静态页面和后台生成页面还有一定市场，但对于企业开发，mvvm是完美的解决方案, 也就意味着前后端的完全分离， 后端只提供数据，展示和交互逻辑完全由前端负责。下面简单介绍一下几个 mvvm 框架的特点。 相同点 组件化 响应式数据绑定 状态和路由管理 不同点 reactjs，facebook 出品，生态丰富，使用 jsx 抽象程度高，学习成本高，大公司使用较多。 vue，华人出品，生态较丰富，使用模板抽象程度较高，学习成本低，中小公司和国内使用较多。 svelet 较新，基于一种新的思路，即将运行时的问题提前到编译器解决，目前在前后端均出现了这样的案例。优势是没有运行时，代码小，性能高，很适合做组件开发。 应用层，即后端 移动互联网的发展催生了很多高并发和大数据量的业务，也造就了云厂商的繁荣和容器技术的发展，devops 和云原生等技术被提出，用于解决后端日益复杂的开发运维问题。以 k8s 的出现为标志，基本解决了云环境下的cpu，内存，网络，存储这些计算资源管理和分配问题，有人说 k8s 是云环境下的操作系统，所以后端的开发不得不考虑基础设施到底是啥的问题。...

spring 系框架如 spring， springboot， springcloud 等已成为 java 开发的标配，笔者也是 spring 系框架的多年用户，它们遵循统一的原则，原理清晰，实现优雅， 更新及时，很多最佳实践慢慢都沉淀为规则，为广大 javaer 提供了很多开箱即用的便利，大大降低开发成本。 官方网站一般是学习和查阅某种技术资料的首选, spring 也不例外. 前段时间，我惊喜的发现它们的官方网站 改版了， 风格更加清爽轻量，访问速度更快，布局更加条理找文档更加方便了。在这个前端框架层出不穷的年代，我有点好奇 spring 的官网前端和后端分别是用 啥做的， 又有啥亮点呢？ 我们来一探究竟。 首页截图 分析网站技术架构有一个不错的工具 wappalyzer, 不过我们这里用不到，因为他家官网源码是开源的。 把源码 clone 下来，README 上面一开始就写着: In addition to the practical purpose of powering Spring’s home on the web, this project is designed to serve as a reference application– resource that developers can use to see how the Spring team have used Spring to implement a real-world app with a few interesting requirements....

halo 发布文章时，需输入 slug，即固定链接地址，有利于搜索引擎收录和提升权重。而中文出现在 url 中并不友好， 所以需要自己想一个 slug，一般是英文或者中文拼音。每次发文章都需要这么想一下不方便，我们来优化一下， 即默认填写文章标题的中文拼音作为 slug。 这里有两个思路，首先想到的是后台去转换，毕竟服务器端资源更多更强大，但需要写一个额外的 api，稍显麻烦。 那先研究一下纯前端 js 有没有合适的解决方案呢？马上调研一下: 百度一下 js 中文 拼音，有不少相关文章，毕竟是比较常见的需求。但排名靠前的文章都是贴在文章中的代码，或者百度网盘， 啥年代了还不知道贴一个仓库地址，不专业不考虑。 github 搜 ‘pinyin’, 找到一些几个不错的仓库。 结合他们的文档和然后分别百度， 搞清楚了他们的优劣: https://github.com/hotoo/pinyin 5.1k star, 常见汉字字典文件 165kB，后端版本有 npm 包，web 版本没有。 https://github.com/sxei/pinyinjs 1.8k star, 常见汉字字典文件 27kB， 无npm包。该作者知晓并借鉴了上面的库，自己整理了字库，且做了JS版拼音输入法，看了效果不错。 https://github.com/creeperyang/pinyin 420 star, 常见汉字字典文件 7kB， 有npm包， 缺点是不支持ie和edeg浏览器。该库转换方原理参见博客利用Android源码，轻松实现汉字转拼音功能，可以算作Java到JavaScript的一次转译。 说明一下，上面的情况都是选择他们的 web 常用字库版,带约 6000+ 汉字也有排序。它们都还有带声调多音子的完整字库版本，需要的自己去深入研究。有人可能会和我一样，觉得 6000+ 常用字够不够，那就来感觉一下，这些常用字你能认识多少先吧: /** * 常规拼音数据字典，收录常见汉字6763个，不支持多音字 */ var pinyin_dict_notone = { "a":"啊阿锕", "ai":"埃挨哎唉哀皑癌蔼矮艾碍爱隘诶捱嗳嗌嫒瑷暧砹锿霭", "an":"鞍氨安俺按暗岸胺案谙埯揞犴庵桉铵鹌顸黯", "ang":"肮昂盎", "ao":"凹敖熬翱袄傲奥懊澳坳拗嗷噢岙廒遨媪骜聱螯鏊鳌鏖", "ba":"芭捌扒叭吧笆八疤巴拔跋靶把耙坝霸罢爸茇菝萆捭岜灞杷钯粑鲅魃", "bai":"白柏百摆佰败拜稗薜掰鞴", "ban":"斑班搬扳般颁板版扮拌伴瓣半办绊阪坂豳钣瘢癍舨", "bang":"邦帮梆榜膀绑棒磅蚌镑傍谤蒡螃", "bao":"苞胞包褒雹保堡饱宝抱报暴豹鲍爆勹葆宀孢煲鸨褓趵龅", "bo":"剥薄玻菠播拨钵波博勃搏铂箔伯帛舶脖膊渤泊驳亳蕃啵饽檗擘礴钹鹁簸跛", "bei":"杯碑悲卑北辈背贝钡倍狈备惫焙被孛陂邶埤蓓呗怫悖碚鹎褙鐾", "ben":"奔苯本笨畚坌锛" // 省略其它 }; 我要优化的这个场景是 halo 博客的后台，发布文章时默认填充一个文章标题的中文拼音作为 slug。...

java web开放中碰到的三个问题 现在维护一个常规java web项目，jquery前端，java 后台， mysql 数据库，这几天开发过程中分别碰到一个问题，不算很冷门，但没碰到过或疏忽了也花费不少时间解决，特记录下来备用及分享。 jquery 的 attr（）和 prop（） 男女两个 radio， 使用 jquery 分别赋值男女多次，最后使用 attr 方法异常，使用 prop 方法正常 <input type="radio" name="sex" value="1"/> 男 <input type="radio" name="sex" value="0"/> 女 $("input[name='sex'][value=1]").attr("checked", true) // ok $("input[name='sex'][value=1]").attr("checked", false) // ok $("input[name='sex'][value=1]").attr("checked", true) // fail，最后男未选中，异常 $("input[name='sex'][value=1]").prop("checked", true) // ok $("input[name='sex'][value=1]").prop("checked", false) // ok $("input[name='sex'][value=1]").prop("checked", true) // ok，最后男选中，正确 原因是jquery较高版本对property和attribute做了区分，（有的说1.6+,有的说1.9+,暂未核实）,较高版本应该使用 prop 方法操作 property: property 它是与生俱来的，并不是后天赋予的。比如说，某些对象在定义时就具有某一些属性。 attribute 本身没有的，后天赋予的。比如说，某些对象在创建后，自定义赋予的一些属性。 下面是官方 https://api.jquery.com/prop/ 的介绍： The difference between attributes and properties can be important in specific situations....

今天碰到一个奇怪的空指针错误，场景大概是这样，从数据库中找出选修了某门课程的学生列表，然后筛选出不及格的考生，要求他们重新考试，部分代码如下 List<Student> list = StudentMapper.findByClass(classId); //找出选修课程的所有学生 list.stream() .filter(x -> x.getScore() < 60) ... 然而上面的代码，运行时会报空指针异常，由于错误信息包在 stream 里面并不是很清晰，我第一个想法就是 x 为空，故 x.getScore(0) 报空指针异常， 然而经过debug， 发现 list 均不是 null。然后我的方向往 stream api 的方向去找了，莫非全过滤调了，或者哪个 api 用错了，一番折腾，依旧没有解决。 最后，我注意到了 x.getScore() 返回的是整型Integer, int 的自动拆封装箱类型，原来不是 x 的值为空，而是x.getScore()的值为空，然后和 60 比较大小时，抛出空指针异常。 由于在其他场景自动拆封装箱使用的挺顺畅，以及编译期不报语法错误，Integer 和int互相比较时，很容易写成较简单的 == 形式，然后就出现了奇怪的空指针异常。 整型比较还有更不容易发现的坑，如下面的代码: Integer i1 = 120; Integer i2 = 120; Integer i3 = 130; Integer i4 = 130; System.out.println(i1==i2); //true System.out.println(i3==i4); //false } 是不是很惊奇？原因是 java 为优化性能，默认创建了值在(-128,128]这个范围内的整型装箱实例。...