今天早上并没有能够成功在五点半起床去坐车，所以，我现在依然在老家。
之所以没能成功，有一些客观因素，不过，不在本文讨论，我们来讨论讨论主观因素。
我的闹钟其实是有两个的：
两个闹钟就是担心我自己不能够起床，不过目前来看，显然两个闹钟是无法拯救我的。
回顾我与两个闹钟战斗的场景，我突然意识到。我之所以起不来，很可能是与下意识关掉闹钟这个行为有关。
下意识关掉闹钟，让我从“你该起床”的场景中剥离出来，可以起床。如果能够控制自己，不要去关掉闹钟，让自己始终处于这样的一个场景中，想来能够更好的刺激自己起床。
再上一篇文章中，我提到了，想要去做一个前端的队列。
和几个朋友聊了聊，他们认为这个东西不值得做，因为没有价值。
在我看来不这样认为。
就这样的话题而言，证实很容易。只要实现，并证明可用，就可以完成证实的内容。
但是，更重要的是证伪，需要证明这个东西，虽然可以做出来，但是并不好用。具体的不好用是多么不好用，具体的量化。这样才能算完成了证伪
今天在 V2ex 和别人讨论我写的《离用户近一点，再近一点》时，提到了队列、3rd API
关于 3rd API 的问题，我可以理解，因为涉及到安全问题，我们需要将 token 放在后端。如果安全问题可以解决，放在前端也不无可能。
关于队列的问题，我就有了想法？为什么不可行？
队列主要问题有三处
关于消息通讯，可以考虑实现 P2P 网络来链接不同的前端设备；而选举问题，可能需要我去看看拜占庭将军问题，以及了解一些数学相关的东西。其中，老王给我了一个思路，可以看看分布式队列的实现逻辑。
调度问题也可以参考分布式队列。
在搜索的过程中，找到了香港城市大学的教授的研究页面。
https://staff.ie.cuhk.edu.hk/~mhchen/projects/p2p.queuing.html
搜索关键词
peer to peer queue
peer to peer message queue
补充信息
搜索过程中，发现问题被简化了，可能有一些可能可以在前端实现队列的工具，比如 ZeroMQ。
作为一个 Engineer ，前「后端工程师」，我用过不少后端框架，比如 PHP 里的 ThinkPHP（3.x）时代，Laravel（5.x）时代，Python 的 Flask、Django ，Ruby 里的 Rails。
其中，近两年我用的最多的是 Laravel 和 Django ，原因是他们提供了一个很重要的 Feature ，就是 Admin Panel。只不过 Django 是官方自带的（Django Admin），而 Laravel 使用的是第三方 Pacakge （Laravel-Admin）。
借助这两个工具，可以快速的生成一个好用且效果非常不错的管理后台，让并不是很喜欢做界面的我大呼爽快（实际上我并不是不喜欢写 JS，我仅仅是不喜欢写 CSS，现在的组件化开发大大的让我解脱出来）。只需要很少的一些代码，就能够完成自己想要的效果。
不过，这样让我产生了一定的依赖，现在要做一些和 Web 相关的事情时，我都会优先考虑 Laravel 和 Django ，因为他们提供了 Admin 后台，可以让我在很长的一段时间内不去关注后台的逻辑，更加专注于前台的开发。
这很好，很敏捷。但是也让我失去了自己开发业务后台的耐性，毕竟，已经有更加简单的实现方式了，为什么还要为难自己呢？
但是，如果你想要认认真真去做一个项目的时候，会发现这种高度简化的代码，让你的拓展性非常的差，你无法更好的去做好自己应该做的事情。
所以，为什么不从一开始就自己写后台呢？虽然慢了点，但是对于你自己来说，也是足够的。随着你自己的开发项目的变多，完全可以做一套你自己的通用后台，完全符合你自己的要求、想法。那才是你真正需要的。
在现代的工业体系下，任何工作都被拆分为流水线上的一环，如今的互联网行业更是从用户那里知道他们想要什么再到实际做出来，有足足六七个环节。
作为一个有写代码爱好的人来说，能选择的余地不多，唯有「后端工程师」和「前端工程师」，在过去的很长时间，我基本上呆在后端的领域，去做了很多后端相关的开发，自己也在后端方面有了更多的认识。
在新的 2019 年，我将会尝试让自己转向，成为一个前端工程师。接下来，我来说一说我这个选择的背后逻辑。
白子：离客户越近，其价值就越大。
提到择业，就避不开两个话题，企业的需求和员工的价值。一般来说，我们认为，员工的价值由他为企业带来的价值所决定。
这句话没错，那么，员工如何为企业带来价值？
员工可以帮助企业创造更好的产品，但是，这是价值么？
更好的产品本身并不是价值，其所带来的用户、客户才是真正的价值。
员工本身并不让企业盈利，相反，企业需要支付费用给员工。而客户则是支付费用给公司，帮助企业盈利。
从这个角度来看，离客户越近的人，越能产生价值，这也就是为什么我们会经常看到一个企业里，销售是赚钱最多的人，因为他们离客户最近，能够给企业带来实打实的价值。
白子：技术本身就是螺丝钉，只研技术，不过是一个螺丝钉，变成一个更粗的螺丝钉。
关注技术本身有没有坏处？当然没有，作为一个开发者，追求技术的卓越是应有的义务。但是，从企业的角度来说，只关注技术本身，意味着你的价值会不断降低。
技术再强，也是可以找到替代者的，区别仅仅是愿不愿意花那么多钱罢了。业务理解的深度，却是其他人无法轻易替代的。江山代有才人出，各领风骚数百年，技术迭代速度非常快，总会有新人出来，比你更加擅长技术。
白子：如今的前端更加接近业务本身，更具备价值
随着现代软件产品的高度流水线化，我们推崇的前后端分离、RESTFul API、GraphQL 让后端的工作越来越轻松，可以花费更多的精力投放在技术深度的探索，去研究更加深层次的优化问题，而不需要花费更多的心思在业务逻辑上去。
同样的，前端不得不承担起业务流程的开发，工作量大大加大。虽然有各种各样的组件库帮助前端优化了具体布局、界面上面的工作，但业务流程本身的复杂度并不会因为组件库的引入而简化。
在这种强前端重后端的模式下，前端承担了原本是后端的工作，让后端不再需要去理解业务逻辑，更加关注技术本身的内容就可以了。离业务越来越远，使得后端的话语权越来越小。
前端工程师本身负责的是客户可以看见的内容，这使得他们相比于后端工程师，有着更多的职业选择。
他们了解用户交互体验，可以从开发转换成为用户研究
他们了解用户使用方法，可以从开发转换成为销售
他们了解用户使用路径，可以从开发转换成为产品经理
而后端，由于专精于技术，其职业选择，也不过是从一门技术，转为另外一门技术罢了。
在接触到了很多小白以后，我开始习惯性的说：
你是什么样的场景需要 XXX 的？
背后的逻辑其实是，你的方法可能无法被你所提出的解决方案所解决，你可以告诉我你实际遇到的问题是什么，我可以借助我的经验，帮你想到一个 workaround 来解决掉这个问题。
年轻人难免会心急，希望快速成长，希望在有限的时间内，获得无限的成长，因此，对于干活的希望是无比渴求的，他们希望自己接收到的都是干活，没有湿货。但是应当注意：
干货如骨架，吸收越来越多的干货，只是让你的骨架越来越大。若是没有足够的湿货来辅助，就是空有骨架，依然不是一个完整的人，只是从一个骨头架子变成了另一个骨头架子。看点湿货，让自己的骨架成长的时候，也有对应的血肉填上，这才是刚刚好的一个人。
湿货看的比干货多的话，一个人就会骨架不强而血肉有余，满口空话，不过是痴肥罢了。
合照助手小程序用于快速在一些聚餐、合照的场合生成合照图片。
用户可以打开手机小程序，选择图片，然后分别输入合照的名称、第一行的顺序、第二行的顺序。然后可以点击保存将图片保存至本地。
适合场景：聚餐、聚会、会议
作为开发者，最常见的问题是，做项目的适合，所做的产品完全无法交付给第三方使用。你所做的东西只能用于自己使用，无法交付给第三方使用时，实际上你并没有交付出去价值。
当你交付出去了价值的时候，世界才能为你定价。所以，做东西尽可能做成可以交付的产品，交付出去产品，让世界为你估价。
以上心得是我在做美食地图时得到的。
在做美食地图时，我需要做以下事情来保证交付：
我很崇尚广度，在有一个深度以后，去追求更多的广度，并试图将广度发展成深度。
不过，这两天在群里看到了另外一种分类的方法：
从另外一个角度来看，也解释了为什么大公司需要的是深度型的人才。
大公司往往业务模型已经确立，他们需要的是人能够把业务更好更快的运转，螺丝钉更适合；而小公司由于没有确定业务模型，需要花时间去做好基础架构，这个时刻广度就非常重要了。