落叶翩翩的CSDN博客

错误信息：X 缓存镜像时失败: Caching images for kubeadm: caching images: caching image "C:\\Users\\86136\\.minikube\\cache\\images\\k8s.gcr.io\\kube-scheduler_v1.18.0": nil image for k8s.gcr.io/kube-scheduler:v1.18.0: Get https://k8s.gcr.io/v2/: dial tcp 74.125.23.82

前后端分离模式下的安全解决方案前言在前后端分离的开发模式中，从开发的角色和职能上来讲，一个最明显的变化就是：以往传统中，只负责浏览器环境中开发的前端同学，需要涉猎到服务端层面，编写服务端代码。而摆在面前的一个基础性问题就是如何保障Web安全？本文就在前后端分离模式的架构下，针对前端在Web开发中，所遇到的安全问题以及应对措施和注意事项，并提出解决方案。

我在小公司待过、也在大公司待过、还作为小公司的咨询顾问在大公司待过很长一段时间，目前还在大公司待。对于个人成长，大公司能给你哪些小公司很难给的机会？这是本文想讨论的主题。技术人员在大公司要面对的问题个人成长，方法大致是两种，第一是主动学，现在互联网这么开放，IT行业中的知识，只要你想学，几乎没有找不到的资料。基本上，稍微靠谱点的技术人才，都具备主动学习的素质，然而这种学习方式，无论是看书、

前言为了解决传统Web开发模式带来的各种问题，我们进行了许多尝试，但由于前/后端的物理鸿沟，尝试的方案都大同小异。痛定思痛，今天我们重新思考了“前后端”的定义，引入前端同学都熟悉的NodeJS，试图探索一条全新的前后端分离模式。随着不同终端(Pad/Mobile/PC)的兴起，对开发人员的要求越来越高，纯浏览器端的响应式已经不能满足用户体验的高要求，我们往往需要针对不同的终端开发定

Windows Server 2008 DNS服务器安装与配置本文关键字：Windows Server 2008 DNS.IIS 服务器安装与配置，DNS服务器本文来源：http://www.ip-tcp.com　　首先，大致的了解一下DNS服务器：它是(Domain Name System或者Domain Name Service)域名系统或者域名服务,域名系统为Internet上的

查看分支：git branch创建分支：git branch 切换分支：git checkout 创建+切换分支：git checkout -b 合并某分支到当前分支：git merge 删除分支：git branch -d

推送分支，就是把该分支上的所有本地提交推送到远程库。推送时，要指定本地分支，这样，Git就会把该分支推送到远程库对应的远程分支上：$ git push origin master如果要推送其他分支，比如dev，就改成：$ git push origin dev但是，并不是一定要把本地分支往远程推送，那么，哪些分支需要推送，哪些不需要呢？master分支是主分支，因此

前言MaxLeap早期是一家研发、运营移动应用和手机游戏公司，发展过程中积累了很多通用组件。这些组件很大程度帮公司在移动研发过程中节省了时间和成本，有没有可能以云服务的方式开放出去，创造更大的价值？延续这个思路，公司成立了云服务部门，尝试服务的商业化。从对内提供接口服务到对外提供云服务，经历了三个阶段发展：1.0时代，定位对内服务，为公司研发的几十款应用提供服务端功能，推送、统一用户管理等

JDK1.5新增的功能   ==>>>字符流和字节流的区别，使用场景，相关类   ==>>>线程安全的概念，实现线程安全的几种方法   ==>>>抽象类和接口的区别，使用场景   ==>>>hash算法的实现原理，hashcode的实现原理   ==>>>error和exception的区别，RuntimeException和非RuntimeException的区别   ==>

为了保障广大APP开发商通过IPv6-only 审核，帮助更多APP顺利进驻Apple Store，全球IPv6测试中心面向APP开发商提供基于APP的IPv6-only预测试业务，具体业务内容如下:APP IPv6-Only预测试服务全球IPv6测试中心模拟苹果APP IPv6审核环境，在IPv6-only网络环境中，对APP各功能模块进行详细的测试，帮助厂商定位和协助解决APP中I

开篇先推荐几篇关于推荐的文章，个人感觉对于入门很有实际意义，是IBM的工程师写的，如下：探索推荐引擎内部的秘密，第 1 部分: 推荐引擎初探探索推荐引擎内部的秘密，第 2 部分: 深入推荐引擎相关算法 - 协同过滤探索推荐引擎内部的秘密，第 3 部分: 深入推荐引擎相关算法 - 聚类推荐两本书，如下：项亮：《推荐系统实践》蒋凡：《推荐系统》推荐系

git log  --since="2008-10-01" --before="2018-11-01"   --oneline --decorate     --no-merges --pretty=format:"%h - %an（%ae） - %s"  >>logs.csv

基于前后端分离的多终端适配前言近年来各站点基于 Web 的多终端适配进行得如火如荼，行业间也发展出依赖各种技术的解决方案。有如基于浏览器原生 CSS3 Media Query 的响应式设计、基于云端智能重排的「云适配」方案等。本文则主要探讨在前后端分离基础下的多终端适配方案。关于前后端分离关于前后端分离的方案，在《前后端分离的思考与实践（一）》中有非常清晰的解释

Nginx + Node.js + Java 的软件栈部署实践起关于前后端分享的思考，我们已经有五篇文章阐述思路与设计。本文介绍淘宝网收藏夹将 Node.js 引入传统技术栈的具体实践。淘宝网线上应用的传统软件栈结构为 Nginx + Velocity + Java，即：

按住ctrl，在画布边缘拖动可以旋转、调整画布大小。右击连接线，可以选择直线连接绘制箭头，点击箭头，箭头处的小圆点用于旋转。

saas特性，请参考我的上一篇博客：http://blog.csdn.net/bolg_hero/article/details/19922201问题提出：     老王是一家小型软件公司的负责人，主要开发erp系统（用java开发的b/s系统），现公司已有一套开发好的erp系统，现在A、B、C公司都和老王签了购买erp系统的合同。老王想基于原来的erp系统修改，又不至于改动太大，并有

XP作为一种还算年轻的软件研发的方法论目前应该可以说开始普及了。作为一个软件研发人员，我非常赞同XP理念，XP的理念中充满了使项目成功的关键思想，而这些思想不仅仅是技术上的，而是很大一部分是管理与沟通方面的。XP集成了许多最佳实践，而这些串连后的最佳实践使整个项目又变的有趣起来，这其中也包括了XP开发人员特有的积极向上的态度与责任心。这里我想向大家描述一下我个人的XP实践感受……下面我分别写一

很多人肯定非常不苟同我的看法，他们认为即使没有做持续集成，甚至没有做阶段集成，但是项目一样按时的完成，甚至提前完成，而且照样完成的非常理想，老板满意，客户满意。而做持续集成，无非就是动不动收到一封邮件，说这个build成功了，那个build失败了，不过就是一持续编译罢了，我自己打个命令编译一下，不就知道了吗？要做个daily build，我还要去set up，还要花力气去配置，效果也不见得好到什么

session管理     为了便于应用节点的扩展的，主要将状态保存到了cookie里面，这样就使得应用节点本身不需要保存任何状态信息，这样在系统用户变多的时候，就可以通过增加更多的应用节点来达到水平扩展的目的。应用拆分     随着用户量增加，业务量增大，新功能不断增加，系统变得越来越复杂，需要对系统按照业务、功能进行拆分，水平和垂直两个方向的拆分，水平方向上，按照功能分为交易，

敏捷软件开发宣言个体和交互 胜过 过程和工具可以工作的软件 胜过 面面俱到客户合作 胜过 合同谈判响应变化 胜过 遵循计划虽然右项也具有价值，但我们认为左项具有更大的价值。敏捷宣言遵循的原则我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意。即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势。经常性地交付可以工作的

插件化备忘一、  概述　　当一个软件项目开发结束并交互使用后，需要添加一些新的功能，我们通常希望在不修改原有的应用程序情况下，将新添加的功能植入到系统中，这就是所谓的插件化，新增加的功能模块就叫插件。插件化能大大的降低模块间的耦合性，有利于各模块的独立维护，加快项目的维护更新。这里记录了下，主流的集中语言，实现插件化的方法。 二、  Java、Net和c/c++ 动态加载方式1

重启PHP-FPMservice php-fpm restart./configure --prefix=/root/tools/php --with-config-file-path=/root/tools/php/etc --enable-fpm --with-pdo-mysql=/root/tools/php/include/php/ext/mysqlnd  --with-m

前不久徐飞写了一篇很好的文章：Web 应用的组件化开发。本文尝试从历史发展角度，说说各种研发模式的优劣。一、简单明快的早期时代可称之为 Web 1.0 时代，非常适合创业型小项目，不分前后端，经常 3-5 人搞定所有开发。页面由 JSP、PHP 等工程师在服务端生成，浏览器负责展现。基本上是服务端给什么浏览器就展现什么，展现的控制在 Web Server 层。这种模式的好处

Midway-ModelProxy — 轻量级的接口配置建模框架前言使用Node做前后端分离的开发模式带来了一些性能及开发流程上的优势(见《前后端分离的思考与实践 一》), 但同时也面临不少挑战。在淘宝复杂的业务及技术架构下，后端必须依赖Java搭建基础架构，同时提供相关业务接口供前端使用。Node在整个环境中最重要的工作之一就是代理这些业务接口，以方便前端(Node端和浏览器端)

基于前后端分离的模版探索前言在做前后端分离时，第一个关注到的问题就是 渲染，也就是 View 这个层面的工作。在传统的开发模式中，浏览器端与服务器端是由不同的前后端两个团队开发，但是模版却又在这两者中间的模糊地带。因此模版上面总不可避免的越来越多复杂逻辑，最终难以维护。而我们选择了NodeJS，作为一个前后端的中间层。试图藉由NodeJS，来疏理 View 层面的工

做软件，我的新尝试，不按软件工程的流程来，先需求分析，在概要、详细设计，然后写代码。另一种模式：先写代码，核心难点攻破几个，碰到了很多问题，很不顺，于是又回头，开始需求分析，关键技术实现有点思路了，但是做的项目可能要重来了呦，这种模式相对瀑布模型的优点知道了一些技术实现细节；缺点是对需求不了解，项目开发很困惑。如果在回头按照瀑布模型在开发一遍，在需求分析阶段可已附加上技术实现细节，两相结合优缺互补