昨天给朋友推荐了React,但心里还真没有底,这里整理下资料,如果不考虑浏览器兼容性的问题,这东东真不错😄。

1. 虚拟dom是什么?

虚拟DOM是HTML DOM的抽象,它和浏览器的实现分离。

2. 为什么虚拟dom快?

DOM拖慢JavaScript。所有的DOM操作都是同步的,会堵塞浏览器。JavaScript操作DOM时,必须等前一个操作结束,才能执行后一个操作。只要一个操作有卡顿,整个网页就会短暂失去响应。浏览器重绘网页的频率是60FPS(即16毫秒/帧),JavaScript做不到在16毫秒内完成DOM操作,因此产生了跳帧。虚拟dom的改变并不会引起浏览器dom的改变,而是由React在合适的时机比较差异并渲染,保证FPS

3. Why is React’s concept of Virtual DOM said to be more performant than dirty model checking?

React knows when to re-render the scene because it is able to observe when this data changes. Dirty checking is slower than observables because you must poll the data at a regular interval and check all of the values in the data structure recursively. By comparison, setting a value on the state will signal to a listener that some state has changed, so React can simply listen for change events on the state and queue up re-rendering.(这点随着es6的Proxy到来,AngularJS会越来越强大😄)

4. What makes React fast ?

  • Batched DOM read/write operations.
  • Efficient update of sub-tree only.

Compared to dirty-check, the key differences IMO are:

Model dirty-checking: React component is explicitly set as dirty whenever setState is called, so there’s no comparison (of the data) needed here. For dirty-checking, the comparison (of the models) always happen each digest loop.

DOM updating: DOM operations are very expensive because modifying the DOM will also apply and calculate CSS styles, layouts. The saved time from unnecessary DOM modification can be longer than the time spent diffing the virtual DOM.

4. What’s the problem of template engine?

Template languages express the initial render of your application, and you’re responsible for manually mutating the state of the UI when your backing data changes and events occur.

5. how to run ?

上面部分是用户触发的,下面部分是定时触发的。

首先说上面部分:

  1. 用户点击某dom
  2. top-level event handler分发事件到指定的event handler

    top-level event handler指的是document上的event handler,这种方式能够提高性能(因为在每个真实的dom上面绑定事件是非常慢的)并且跨浏览器(浏览器中的事件本身就没有统一)

  3. 用户代码调用setState()

    AngularJS双向绑定,不需要用户调用状态变更。所以,必须要去做大量的dirty check。虽然是一种倒退,但是为了性能忍了,等ES6吧。

下面部分的逻辑:event loop周期性的检查有状态组件是否dirty,然后通过diff算法批量更新浏览器dom树。

情绪地雷区避雷方案:

  1. 安排B计划 (比如等人吃饭,提前准备点事做,别人没到就做自己的事)
  2. 公开自己的情绪死穴 (比如提前给人说哪些是不喜欢的,如果你这样做了,我也避免不了我不发脾气)

情绪管理在生活与工作中的应用

  1. 正向思考

    凡事往正面的角度去想,选取对自己最有利的注解

  2. 转移注意力

    去做能带来好情绪的活动或事情。比如吃自己最喜爱的食物

  3. 让开放的肢体动作带动情绪

    比如去爬山,去跑步,去旅游。

  4. 透过问句引导自己改变认知

     a.对方是故意的还是无心的?
     b.这件事还有没有其他角度与意义可以让我感觉更好?
     c.如果我希望自己的情绪变好,现在我应该做什么?
     d.这样做是真的会让情绪变好还是会有后遗症?
     e.我可以寻求谁的帮助来改善自己的情绪?
    
  5. 发现自己情绪有失控的感觉或倾向,必要时离开现场
  6. 把不满、愤怒、失意等负面情绪写在纸上,然后烧掉、冲掉、寄出或者收藏
  7. 了解自身的有点,积极表现自己,但求尽心尽力
  8. 多看别人的好,适度予以宽容的对待
  9. 接近拥有心灵智慧的良师益友

    智慧不起烦恼,慈悲没有敌人

  10. 提醒自己:世间事都只是过程而非结果

    每件事最终都会过去,包括我自己(凡人必有一死)

  11. 全力以赴后,放下得失心,因为你没有办法决定所有的事一定如你所愿

    战胜对手只是人生的赢家,战胜自己才是命运的强者

哈佛大学推荐20个快乐的习惯

  1. be grateful (学会感恩)

    让自己变慢脚步,看看你的四周,关注生活中的细微之处:人行道上淡紫色的花,美丽的日落,洗去你一天疲惫的淋浴,伴侣眼中的笑容。当你的感恩之心能够欣赏生活的美,思考和祝福,你自然就充满了幸福感。

  2. choose your friedns wisely

    如果你想变得开心的话,要选择和乐观的朋友在一起,他们能欣赏你真实的自己,让你的生活变得更丰富,快乐,有意义。

  3. cultivate compassion (培养同情心)

    当我们代替别人,站在另一个角度看问题,我们更能用同情心,客观和有效的处理问题。生活中就会少一些冲突,多一点快乐。

  4. keep leaning

    学习让我们保持年轻,梦想让我们充满活力。我们运用大脑,进行运作的时候,我们就不大会想不开心心的事情,我们会变得更开心和满足。

  5. become a problem solver (学会解决问题)
  6. do what you love
  7. live in the present

    你感到沮丧,是因为你活在过去。你会感到担忧和焦虑,是因为你活在未来。但是当你感到满足,开心和平和时,你才是活在当下。

  8. laugh often

     笑是对抗生气或沮丧最有力的的东西。不要把生活看的太严肃。要学会在每日的奋斗中寻找幽默感和笑声。  

  9. practice forgiveness

    憎恨和生气是对自我的惩罚。当你释怀的时候,事实上你是在对自己施以善意。最重要的是,学会原谅自己。每个人都犯错。只有通过我们的错误,我们才慢慢学会如何成为一个更强大,更好的人。

  10. say thanks often

    对生活中的祝福要学会欣赏。向那些让你生活变好的人,无论或大或小,表达出你的欣赏之情也同样重要。

  11. create deeper connections (学会深交)

    我们的幸福感会在和另一个人的深交中不断猛增。专注聆听是加强这种关系纽带和把幸福感带给自己和别人的两个最重要的方面。

  12. keep you agreement

    我们的自尊是建立在我们对自己守承诺的情况下。高度的自尊和幸福感有直接关联。所以要对自己和别人遵守承诺。

  13. meditate (冥想)
  14. focus on what you’re doing

    当你全身心投入一件事的时候,你就会处于一个开心的状态。当我们处于这种状态,你就不大会关心别人对你怎么看,不大会被不大重要的事情干扰。结果呢?更幸福,当然啦!

  15. be optimistic

    对于开心的人来说,玻璃都一直是半满的。每当你面对一个挑战时,如果你倾向于想象最坏的想法,那就自我转换这种情况。告诉你自己一个状况中的好处或者你从中学到的东西。乐观肯定能驱动成功和幸福感。

  16. love unconditionally

    没人是完美的,接受你自己所有的不完美,也要这样对待别人。无条件的爱一个人并不意味着你要花所有的时间和他们在一起,或者帮助他们解决问题。无条件的爱意味着接受真实的他们,以他们自己的步伐,让他们自己摸索。

  17. don’t give up

    没有完成的方案和不断的失败不可避免的会削弱你的自尊。如果你决定做某事,做完它。

  18. do you best and then let go

    每个人都有局限性。而且有时候尽管我们很努力做一件事情,但是总会事与愿违。所以做最好的自己,然后放手。当你尽了全力,你就没有遗憾了。

  19. take care of yourself

    一个健康的身体是幸福的关键。如果你身体不好,你无论如何努力,都很难快乐。确信自己吃得好,做锻炼,找点时间休息。好好照顾你的身体,大脑和精神。

  20. give back (学会给予)

    做好事是最能确保你心情好的方法之一。根据哈佛,人们做好事,他们的大脑变得活跃,就好像当你经历别的奖励时,大脑所受的刺激。所以,那些关心别人的人要比不大关心别人的人更开心。

Next Generation Session Management with Spring Session

http://www.infoq.com/articles/Next-Generation-Session-Management-with-Spring-Session

在大规模集群的场景,无状态的应用能减少运维成本、缩短应用恢复时间。spring session主要解决了web应用session持久化的问题。把session存储在应用外部,让应用无状态。

spring session主要提供如下能力:

  1. 把session的存储逻辑抽取出来,可以选择rdis,或者自己实现session存储
  2. 使用websocket也能保持会话
  3. 非web应用也能使用会话
  4. 支持多个session(可以登陆多个用户)
  5. Restful API也能通过http header维护会话

spring session 1.1版本支持HttpSessionListener.如果使用的redis,spring session通过key过期时的过期事件+redis消息推送来实现。可惜我们用的是codis,我们实现了DisabledRedisMessageListenerContainer把这个能力屏蔽了。

更多参考:spring session 官方文档 Add HttpSessionListener Support

The Twelve-Factor App

http://12factor.net

The twelve-factor app is a methodology for building software-as-a-service apps.

  1. Codebase:One codebase tracked in revision control, many deploys

    one codebase per app(all tracked in revision control), but there will be many deploys of the app(one or more staging use same code,use multi config file or configuration management system for different stage ).

  2. Dependencies:Explicitly declare and isolate dependencies

    declares all dependencies via a dependency declaration manifest,and use dependencies check strategy to ensure that no implicit dependencies.

  3. Config:Store config in the environment

    use mutli config file (build env-awared app) or use configuration management system (spring cloud config

  4. Backing Services:Treat backing services as attached resources

    app makes no distinction between local and third party services(both are attached resources). A deploy should be able to swap out a local MySQL database with one managed by a third party (such as Amazon RDS) without any changes to the app’s code.

  5. Build, release, run:Strictly separate build and run stages

    app uses strict separation between the build, release, and run stages. For example, it is impossible to make changes to the code at runtime, since there is no way to propagate those changes back to the build stage(we can put dynamic part code into db ).

  6. Processes:Execute the app as one or more stateless processes

    Twelve-factor processes are stateless and share-nothing. Any data that needs to persist must be stored in a stateful backing service, typically a database.Sticky sessions should never be used or relied upon.

  7. Port binding:Export services via port binding

    The twelve-factor app is completely self-contained and does not rely on runtime injection of a webserver into the execution environment to create a web-facing service. The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port.

  8. Concurrency:Scale out via the process model

    processes are a first class citizen.Processes in the twelve-factor app take strong cues from the unix process model for running service daemons. Using this model, the developer can architect their app to handle diverse workloads by assigning each type of work to a process type.

  9. Disposability:Maximize robustness with fast startup and graceful shutdown

    Processes should strive to minimize startup time.

    Processes shut down gracefully ( ceasing to listen on the service port,thereby refusing any new requests, allowing any current requests to finish, and then exiting.)when they receive a SIGTERM signal from the process manager.

    For a worker process, graceful shutdown is achieved by returning the current job to the work queue.Implicit in this model is that all jobs are reentrant, which typically is achieved by wrapping the results in a transaction, or making the operation idempotent.

    Processes should also be robust against sudden death, in the case of a failure in the underlying hardware. A recommended approach is use of a robust queueing backend that returns jobs to the queue when clients disconnect or time out. Either way, a twelve-factor app is architected to handle unexpected, non-graceful terminations.

  10. Dev/prod parity:Keep development, staging, and production as similar as possible

    x Traditional app Twelve-factor app
    Time between deploys Weeks Hours
    Code authors vs code deployers Different people Same people
    Dev vs production environments Divergent As similar as possible

    The twelve-factor developer resists the urge to use different backing services between development and production, even when adapters theoretically abstract away any differences in backing services.

  11. Logs:Treat logs as event streams

    A twelve-factor app never concerns itself with routing or storage of its output stream(maybe dont fit for java app).

  12. Admin processes:Run admin/management tasks as one-off processes

    One-off admin processes should be run in an identical environment as the regular long-running processes of the app. They run against a release, using the same codebase and config as any process run against that release. Admin code must ship with application code to avoid synchronization issues.