我最熟悉的技术领域是软件开发和系统架构。在这个领域，我有以下一些深刻的见解：
可维护性和可扩展性：在软件开发过程中，注重代码的可维护性和可扩展性非常重要。良好的软件架构和设计模式能够降低系统的复杂度，提高代码的可读性和可维护性，同时也方便后续的扩展和修改。
用户体验和功能性：用户体验是软件开发的重要指标之一。除了满足功能需求外，还需要注重用户界面的设计和交互体验，以提高用户的满意度和使用效率。
安全性和隐私保护：随着互联网的发展，安全性和隐私保护越来越受到关注。在软件开发过程中，需要充分考虑系统的安全性，采取有效的安全措施保护用户的隐私和数据安全。
性能优化和稳定性：性能优化和系统稳定性是软件开发过程中需要重点关注的问题。通过合理的算法设计、数据库优化、缓存技术等手段，可以提高系统的响应速度和稳定性，提升用户体验。
持续集成和持续交付：持续集成和持续交付是现代软件开发的重要实践，能够提高团队的开发效率和交付速度，减少错误和问题的发现时间，同时也能够更快地响应市场需求。
团队协作和沟通：团队协作和沟通是软件开发过程中至关重要的因素。良好的团队合作和有效的沟通能够促进问题的及时 ...
解决技术难题通常需要系统性的方法和具体的行动步骤。以下是我解决技术难题时常用的一些方法，并列举一个具体的例子：
分析问题：首先，我会仔细分析技术难题的根本原因和影响范围。这可能涉及到查看相关代码、日志或者其他相关文档，以了解问题的背景和上下文。
查阅资料：我会查阅相关的技术文档、书籍、论坛或者社区，寻找类似问题的解决方案或者相关的经验分享。这有助于扩展我的视野，了解不同的解决方法和技术方案。
实验验证：我会尝试使用不同的方法或者技术方案来解决问题，并进行实验验证。这可能包括编写测试代码、模拟场景、调试程序等，以确认解决方案的有效性和可行性。
与同事讨论：在解决技术难题的过程中，我会与同事进行讨论和交流，分享问题的思路和解决方案，听取他们的建议和意见。这有助于获得不同的视角和思路，可能会带来新的灵感和解决方案。
持续学习和尝试：我相信持续学习是解决技术难题的关键。我会不断学习新的技术和工具，提升自己的技术能力和解决问题的能力，并不断尝试新的方法和思路，以找到最佳的解决方案。
具体来说，我曾经遇到过一个系统性能问题，用户反馈系统响应速度较慢。经过分析发现，数据库查询是导致系统 ...
人生思绪
未读作为一个80后，不知不觉一转眼已经三十出头了，突然发现自己的手握的时间已经不多了，却依然觉得内心是个小孩。面对着社会和家庭的责任，一些莫名的焦虑油然而生：感叹时间不够、抱怨老天对自己太不公平、困惑于为何付出没有回报等等。有时候也会觉得工作没有成就感，生活没有幸福感，未来看不到希望，人生好像一团糟。
在学习了王阳明的“心学”以后，我明白了与其焦虑、恐惧、逃避，不如调整心态，积极的去面对。其实小孩和大人最大的人格区别就是“自控力”——保持专注度，在对的时间做对的事情。可惜当我们离开学校后，已经没有人给我们规划学习任务，严格安排好我们每天的学习，没有老师的谆谆教诲，没有学期考试告诉我们那里学得不好。毕业的后，我们看似自由了，但也让我们觉得自己碌碌无为。我突然意识到我的人生需要管理。我们能管理好自己，才能管理好自己的周遭。因此，学习了张萌的《高效能人生的自我管理》，感觉收获很大，因此对其内容进行了总结和摘要。
什么是“人生的效率”？“人生的效率”其实就是在你可支配的时间里，你为的梦想付出了多少有效努力，如果用公式来表示就是：人生效率=（梦想-现状）/可奋斗时间
努力之前一定 ...
关于案例中管理者的问题，我也只是给到个人的思路和看法，仅是一家之言：如果想有效地解决一个问题，首先要界定问题，也就是重新定义问题。
所以我上来先和管理者确认是想排好期（做事的范畴）还是想提升员工主动性（带人的范畴），不同的问题对应着不同的应对手段。看上去目前是更倾向于后者的。
那么好了，员工主动性不高，原因又在哪里呢？我们又可以从三个层次来看：
-知不知：认知。如果是认知问题，学习、辅导、主题明确的交流，都能扩展认知、交换意见，就好像群里各位的探讨一样，大家千万不要认为和我们意见相左的人就一定是错的，群里的都是比较优秀的人，他们一定是基于他们的「成功经验」来发表看法的。所以我们最好带着扩展认知的心态来看待差异。
-愿不愿：意愿。激发意愿有长期的做法也有短期的做法，可以参考咱们的书和专栏。短期可以采取的措施我临时想到的有：
a）明确项目的意义和价值。
b）和成长、发展机会挂钩
c）和个人的回馈挂钩（外部奖惩奖励对执行性的工作有正向意义的）。
如果是整个团队意愿都不高，那么可以考虑找核心成员逐个找突破口，避免把整个团队放在自己的对立面。你看任正非也会区分美国政客和商人不是 ：）
-能不能 ...
目录
前言
1. 对外语学习的主要误区
2. 造成“哑巴英语”的最主要原因
3. 英语环境的问题
4. 特殊群体
5. 语言关键期之争
6. 语言条件反射
7. 关于记忆力 8. 中国“英”雄 9. 二律背反？ 10. 世纪之战 11. “学得”-“获得”之辩 12. 克氏理论
实践篇
第一阶段、早期（Early Stage）
1. 看图识音 2. 全身反应法(Total Physical Response)
第二阶段、提高期(Upping the Ante)
1. 听力内容设计 2. 纽约人在北京 v.s 北京人在纽约 3. 寻找人工替代品 4. 末世圣徒 5. 偏要当文盲 6. 倔强的拉丁文教师 7. 最香、最亲、最爱，也最臭、最烦、最恨（背单词） 8. 美国文盲4000万！ （阅读与拼写） 9. “字母读音法”大战“整体语言法”（Phonics vs. Whole Language） 10. 中国人都是“字林高手”
第三阶段、增长期(Getting Se ...
诊断
有不少管理者常常会对自己产生怀疑，觉得自己不适合做管理，比如下面的这些说法。
我是个内向的人，不像 A 那么热情洋溢，让我慷慨激昂地给大家打鸡血会很有挑战。
我是个女生，不喜欢和大家抽烟喝酒扯闲篇，很难和大家打成一片。
管理者是不是不能太平易近人？亲和力太强的领导，下属会不敬重，因为不够威严。
类似这样的疑问还有很多，他们的共同模式是：先设置一个所谓「好」的管理风格，然后发现自己做不到，于是很苦恼。
其实这些管理者混淆了管理风格和领导力的高低，把两件事混为一谈。
应对思路
领导风格
管理风格属于「手段」的范畴，而领导力的高低属于「结果」的范畴。认为某种风格的领导力一定比自己的风格领导力高，只是一种下意识的观念。而实际上，领导力高低取决于「带团队成事」的能力，而并非由风格决定。
比如案例中的管理者可以意识到自己「沟通、表达从同事和老板的反馈看来没有问题。我自己做事没什么太大问题」，但是「主要担心自己内心是典型的内向性格」。显然是误认为只有某种领导风格才能做好管理工作。
模仿，是人们学习新技能非常重要和常见的方式。榜样给了你前进的方向、动力和信心，这对成长来说是很积极 ...
spring-cloud
未读概述
springCloud feign主要对netflix feign进行了增强和包装，本篇从源码角度带你过一遍装配流程，揭开feign底层的神秘面纱。 主要包括feign整合ribbon，hystrix，sleuth，以及生成的代理类最终注入到spring容器的过程。篇幅略长，耐心读完，相信你会有所收获。
Feign架构图一些核心类及大致流程：
大体步骤： 一、注册FeignClient配置类和FeignClient BeanDefinition 二、实例化Feign上下文对象FeignContext 三、创建 Feign.builder 对象 四、生成负载均衡代理类 五、生成默认代理类 六、注入到spring容器
源码分析主要围绕上面6个步骤详细分析。
一、注册FeignClient配置类和FeignClient BeanDefinition从启动类注解开始，来看下 @EnableFeignClients注解：
123@EnableFeignClients public class MyApplication {}
这是在启动类开启feign装 ...
spring-cloud
未读目录
一、最原始直接
二、AOP
三、拦截器+方法参数解析器
3.1 自定义权限拦截器
3.2 自定义参数注解
3.3 自定义方法参数解析器
3.4 配置MVC
环境：SpringBoot 2.0.4.RELEASE
需求：很多Controller方法，刚进来要先获取当前登录用户的信息，以便做后续的用户相关操作。
准备工作：前端每次请求都传token，后端封装一方法tokenUtils.getUserByToken(token)，根据token解析得到currentUserInfo。
这是一个常见的业务需求，为实现这个需求，有以下几种解决方案：
一、最原始直接即，每个Controller开始，先调用tokenUtils.getUserByToken(token)，不够优雅。
二、AOPAOP可以解决很多切面类问题，将currentUser放到request里；比起拦截器稍重。
三、拦截器+方法参数解析器使用mvc拦截器HandlerInterceptor+方法参数解析器HandlerMethodArgumentResolver最合适。
SpringMVC提供了mvc拦截器 ...
下面我假定，你已经理解了 OAuth 2.0 的含义和设计思想，否则请先阅读这个系列的上一篇文章。
进入正文之前，插播一则活动消息。
4月22日（周一）到4月29日（下周一），每天晚上八点都有两小时的免费直播课，体系化介绍高级前端开发知识，网易云课堂主办。详细介绍请看本文结尾，欢迎关注。
RFC 6749OAuth 2.0 的标准是 RFC 6749 文件。该文件先解释了 OAuth 是什么。
OAuth 引入了一个授权层，用来分离两种不同的角色：客户端和资源所有者。……资源所有者同意以后，资源服务器可以向客户端颁发令牌。客户端通过令牌，去请求数据。
这段话的意思就是，**OAuth 的核心就是向第三方应用颁发令牌。**然后，RFC 6749 接着写道：
（由于互联网有多种场景，）本标准定义了获得令牌的四种授权方式（authorization grant ）。
也就是说，**OAuth 2.0 规定了四种获得令牌的流程。你可以选择最适合自己的那一种，向第三方应用颁发令牌。**下面就是这四种授权方式。
授权码（authorization-code）
隐藏式（implic ...
在spring中，filter都默认继承OncePerRequestFilter，但为什么要这样呢？
OncePerRequestFilter顾名思义，他能够确保在一次请求只通过一次filter，而不需要重复执行。
12345678910111213141516171819202122public final void doFilter(ServletRequest request, ServletResponse response, FilterChain filterChain) throws ServletException, IOException { if(request instanceof HttpServletRequest && response instanceof HttpServletResponse) { HttpServletRequest httpRequest = (HttpServletRequest)request; HttpServletResponse ...
