去年年初做项目的时候接触到了OAuth认证，当时是选用了一个opensource的叫做KeyCloak的产品。项目中学到了很多关于认证的知识，之后一直想简单做下总结来着，后来一直拖了快一年。这几天又重新拾起来。可是，等自己查阅了几篇文章开始着手写的时候，才发现我对于OAuth和OpenIdConnect的理解实在是太浅薄了。 我知道想要深入理解和掌握OAuth 和OpenIdConnect自己还有相当大的距离，现在姑且只把我之前学到的东西总结一下，只当是自己的学习笔记了。 提到认证，可能最先想到的就是账号密码的认证方式。例如BASIC认证，在web服务器端设置好账号密码后可以应用到所有的http请求页中。但是，它的缺点非常显而易见： ・每次请求都需要输入账号密码 ・每次通信内容中都有账号密码的信息，信息泄漏的危险性很大 因为传统账号密码认证方式的诸多缺点，web服务大部分都使用了如下方式： 只在第一次登陆的时候提交账号密码，然后把认证完了的状态存放在session里面，client通过把session_id传递给服务器，服务器就可以判定请求来自于谁，以及是不是经过认证了。 这种认证方式里面已经开始出现了认证和认可的概念了。认证是判定请求来自于谁。而认可是判定是不是经过认证了。 (据说认证和认可就是OAuth和OpenIdConnect的区别) 上面的方式基本实现了认证和认可的功能，但是后来出现了稍微复杂的情况：如何能在多个服务器之间共享认证和认可的信息。例如如何用QQ号登陆百度就是一个很典型的例子。 这种情况下就需要用到OAuth认证方式了，先简单概括一下： QQ拥有用户信息，负责认证，拿QQ号登录成功以后，QQ将认可状态交付给百度，百度记录下认证状态，然后就可以访问百度的服务了(也就是说百度负责认可)。 具体的认证过程可以参照下面的图示： ※本图来自于 http://www.atmarkit.co.jp/ 在这个流程中有那么几个关键词需要解释一下： ・client_id、secrect 由调用的service provider(上面例子中的QQ服务器端)发行的用来识别client(百度)的信息。一般来说，secret不用每次都发送。 ・code 认可代码，用户认证完毕以后，由service provider返回的代码，受到认可代码就可以判定认证OK了。 ・access_token 认证完毕以后，如果想要调用service
Author: tony56
关于买房好还是租房好这个问题，我自己是属于买房派的。 主要有那么几个原因： 1.买房虽然增加了负债，但是可以减少支出。而且长期来看，房贷还完了房子可以变成资产，但是钱支出了就回不来了。 这里想提一下收入，支出，资产和负债这4个名词。 收入：你工作得到的工资，这个不难理解。 支出：衣食住行，娱乐学习等花钱的活动，是你的支出。 资产：可以卖掉换钱的是你的资产，当然存款也是。 负债：你钱别人的钱就是负债。 其实概念很容易理解，但是理解并处理好它们几个的关系就不那么容易了。 就拿买房这件事来说，我们来看看下面几个例子： A君是租房派，每个月拿出十几万日元来租房子，然后每隔两年还要交更新料，二十年过去了，A君租房子的钱够买一套新房了。 B君是买房派，贷款买了房子，每个月换十几万，过了二十几年，B君把贷款还完了，然后房子是自己的了。 C君也买房租房派，因为家里有父母留下的房产，自己又贷款买了房子，然后把自己买的新房租出去了，每个月拿十几万的房租，过了二十几年，C君拿到的房租又够买一套房子了。 很多人都遗憾自己不像C君那样幸运，有父母留下的房产，但是如果你真正明白了为何C君比A君和B君都有钱，你就知道我想要传递的信息了。 A君没有贷款，不同担心没了工作还不起贷款。 B君没有房租的支出，虽然交着贷款但是减少了房租的支出。 C君呢，他既减少了房租的支出，又拥有这能赚钱的资产。 说到这里已经很明白了，想要像C君那样，就要考虑如何既能减少支出，又能增加自己的资产。 2.基于日本的购房免税政策，一定期限内还完房贷的话，没有多交利息钱，反而税钱少交了。 2016年，贷款买房的银行利率大概在0.625%左右。 假设贷款4000万，每年换20万，20年还完的话，大概需要还4250万（4000+4000/2*0.00625*20）。 借了4000万，完了多还给银行250万。是不是很窝火。 不过根据免税政策，其实很还是能省不少钱： 上面这张表计算出了10年内交的利息跟免税金额。 因为免税部分的利率高于银行利率，所以很明显这些钱弥补了你交的利息钱。
其实说来也是惭愧，来了日本都工作了五年了，竟然一直都不明白怎么看「源泉徴収票」。 最近因为在看一本理财相关的书，为了弄明白自己赚的工资究竟都到哪里去了， 于是就费了番功夫，终于算是把它的计算方法弄明白了。 要想看懂「源泉徴収票」,必须先弄明白以下几个名词： ・年収（支払総額） 一年之内税前收入的总额 ・給与所得控除 这个可以理解为年收里免税的金额，计算方法如下： 年收金额 扣除金额 0-180万円 収入金額×40％、下限为65万円 180万円-360万円 収入金額×30％＋18万円 360万円-660万円 収入金額×20％＋54万円 660万円-1000万円 収入金額×10％＋120万円 1000万円-1500万円 収入金額×5％＋170万円 1000万円- 230万円 ※2016年基准 ・所得金额 简单的说:年收-給与所得控除=所得金额
一直觉得那些能写博客或者知乎上能得到很多赞的人很了不起，他们不仅对于自己掌握的知识理解的很透彻，还能讲他们通俗易懂的解释给别人。我一直都不太擅于总结，感觉自己花了很多时间去学习，接触到的知识也不少，但是真正能为己所用，并且表述出来的很少。其实，只有你自己把你学到的表述出来了，你才是真正的掌握了它们。或许有时候是因为太忙，没时间，而忘记了总结。但是其实大部分时候还是因为太懒而放弃了总结。 最近工作中为一个系统的服务器更换而做了一些调优的设置。感觉解决问题的思路是这次收获最大的。因此尝试着进行了下总结： 首先，为何要做这次性能调优的工作。 之前我们的系统运行在tomcat+apache架构组成的6台服务器上。但是因为性能逐渐不足，加上之前的服务器是跟别的系统共用，已经没办法再扩展了。所以决定搬到一个全新构建的服务器集群下。加之公司规定，新构建的系统一概采用Nginx+Wildfly的架构，所以新环境里采用了Nginx+Wildfly的架构，而为了达到对硬件资源的有效利用，对它们分别进行了一些性能的调优。 关于性能调优的一个基本的思路，我的理解如下： 影响服务器性能的三个主要因素： CPU(计算能力)+IO(读写能力)＋内存(存储能力) 测试达到最大性能时的瓶颈因素，然后找到原因，尝试修改中间件的设置或者系统代码去降低瓶颈值，以便让所有资源得到充分利用。 找到瓶颈很简单，但是找到原因就不太容易了，总结下到到目前为止遇到和处理过的问题，我给出一下几个建议： 如果系统逻辑很复杂，最好检查最耗费资源的处理是不是妥当(分析Thread dump) 如果对象是db服务器，需要查找最耗时的sql需不需要能够优化(分析Sql dump) 如果服务器资源还没达到最大利用率但是处理件数却已经达到极限，就需要看看中间件的设置是不是有问题(调整heap size、thread pool等设置)。 然后，分享下这次调优的过程： 测试工具：Jmeter 测试客户机：5台左右 服务器架构：web服务器1台(nginx)，application服务器1台(wildfly) 服务器硬件：web服务器跟application服务器分别是2核cpu，4G内存，100G硬盘(无ssd) ①逐渐调整Jmeter件数，大概在每秒900/件的时候，错误开始频繁发生 ②通过log查找出错误的原因在Web服务器(Nginx) 错误内容： socket()
现在担当的一个ec网，前不久因为系统bug，出现了未给部分用户计算折扣的现象。因为用户的id输出到了日志中，后来就把这些id抽出来，通过跟另外一个master文件进行对比的方法来进行恢复工作。 插图 一般这种情况下，使用excel的vlookup函数都能够简单实现，但是因为母数据有30万件，直接粘贴到excel里面会导致系统死机，而这些数据因为都是个人情报，不能从没有数据库的商业环境里抽取出来，所以很是麻烦。 大家都束手无策的时候我当时提议拿java写个程序去查找。虽然现在看起来很傻，但是当时大家还是相当欣赏这个提议的。至少不需要人海战术去手动查了。 记得当时时候拿java写了这么个小程序： idFile = openFile(开存放id的文件) while(line = idFile读取一行)｛ masterFile = openFile(master文件) while(target = masterFile读取一行)｛ if(line == target) { 输出line break; } ｝
MapReduceでググたら、下記の説明文が出てきました： MapReduce（マップリデュース）は、コンピューター機器のクラスター上での巨大なデータセットに対する分散コンピューティングを支援する目的で、Googleによって2004年に導入されたプログラミングモデルである。 分散コンピュータリング処理のことらしい。実際どんなふうに分散するでしょうか？ 下の図がとてもわかりやすく説明できていると思います。 ※From ITMedia やりたいこととしては、Inputを処理して、Outputを出したい。 その手順は下記のイメージ： ①Inputを分割して、複数のworkerにアサインする(Readステップ) ②それぞれのworkerが決められたルールで自分をのnputをさらに分割する(Mapステップ) ③Mapステップで処理した結果をもらって、複数のworkerがOutputをだすために処理を行う(Reduceステップ) ④Reduceで処理した内容をOutputに変換する(Writeステップ) この処理フローは順次実行のプログラムより複雑のように見えますが、 ビッグデータを処理する際は、この処理フローを使うと、複数のスレッドまたはサーバに分散＆並列処理ができます。 ※MapとReduceのロジックだけ考えればいい http://www.atmarkit.co.jp/ait/articles/0807/08/news119.html https://ja.wikipedia.org/wiki/MapReduce
一个B树的小演示。目前可以叠加两层。三层以上的问题还尚未解决。 参考网址： http://www.atmarkit.co.jp/fcoding/articles/delphi/05/delphi05a.html
一直以为3d图形编程是那么的困难，在此之前也从没触及过。直到前几天，一次非常偶然的机会，需要做一个类似于ipod的专辑滑动效果的flash，从网上找到了一个叫做coverflow的特效，阅读了源代码，才发现，3d图形编程其实也还挺简单的。 之前之所以认为困难，尤其是因为搞不懂如果在一个3d空间里视角转换了的话看到的物体究竟会怎么变，说实话，如果从0开始想怎么用程序去实现的话确实很困难，但是如果使用构造好的模型或者说是引擎来去实现的话，一切就都简单了。
