why

公司最近上了一套中台服务,因为好奇所以查了一下资料,中台是为了提高开发效率,将各个服务中共同的组织,资源集中管理,作为一个整体服务,宏观上我们可以把淘宝客户端,盒马生鲜,饿了么看做大前端,而他们有一部分共享数据,比如用户信息,支付功能,搜索功能等

又比如我们公司的电商平台,核心系统包括,ERP(企业资源计划即 ERP Enterprise Resource Planning),WMS(仓库管理系统Warehouse Management System)以及一套交付系统(包含购买,安装服务,维修服务,代理商管理等),他们需要共享商品信息,ERP需要用来算账,WMS需要用来发货,交付系统需要用来记录他的生命周期,就在中台配置一套信息,就可以达到三套系统都可以访问的效果。

what

中台也可以分类:

  • 业务中台(如上举例我们公司的业务)
  • 技术中台(如淘宝的中台,当然也有偏业务的部分,主要目的防止重复造轮子)
  • 数据中台(包括建模,日志分析,profile)
  • 算法中台(推荐算法,搜索算法等)

feature

目前中台还是比较烧钱的吧,公司没有到达一定的规模,这个东西还是没有什么卵用,我们目前上了一套ERP,一套中台,级别在千万吧,还需要各个部门进行配合,进行系统整合(以前都是各干各的,系统间几乎没有交互,重复造轮子)。恶心的我啊,加了10117了三个月才大体上能用了

不过我觉得中台的发展历史可能和服务一样,一个整体的服务臃肿,后续的中台还是会变成中心化,即一个核心业务,其他做成微服务,分布式的架构,是目前技术潮流的前进方向

why

日志是用来记录程序运行重要的工具

  • 记录请求日志,关键节点打上日志,可以追踪问题(生产
  • 方便调试,定位故障
  • 监控应用的运行状态

what(egg.js为例)

日志分为:

  • appLogger应用日志,也是我们自定义的日志
  • coreLogger核心框架,插件日志
  • errorLogger
  • agentLogger用于监控agent日志

日志级别:

  • ctx.logger.debug()
  • ctx.logger.info()
  • ctx.logger.warn()
  • ctx.logger.error()
  • 以appLogger为例,一共4*4种

日志编码:

  • 默认utf-8

feature

目前日志都支持切割,每天一个文件,以.log.2019-09-14为尾缀(小时切割和文件大小切割实用性不高),编写日志的时候我们也需要注意如下几点:

  • 在关键请求关键位置打好日志

  • 打印日志注明这是哪个文件哪个方法处理的日志

    • logger.debug(`>>>> Entering yourMethod(month = ${month}, count= ${count}");
      //通过日志 >>>> 和 <<<< 将给出函数输入和退出的信息
      
  • 日志不能太多,一个是查问题日志太多,第二个是对硬盘写入日志也有一定性能影响(egg是写入内存,每秒保存一次硬盘)

  • 合理使用try-catch来进行日志输出

  • 日志写法一定要避免简洁,不要日志再抛错(正常打印参数,打印处理结果)

  • 日志不能具备除了日志以外的功能

  • 正确把握日志级别,info记录信息(最主要的),debug显示调试信息,warn显示警告,error保存数据库请求类型的报错

  • 尽量使用ctx.logger而并非console.log,后者将会把所有日志打印在stdout中,无法关闭或打开调试信息,并且不区分级别

5月1日搭车去了绍兴,一个是自己毕业后其实既没有毕业旅行,也没有去哪里玩儿,所以想补偿自己一下,第二个是我表姐给我买了票了,想着还是去吧。

因为最后一个工作日加了个班,然后又起得很早,读着东野圭吾的《嫌疑人X的献身》,中午饿了就在高铁上买了15元的盒饭,拿着kindle强行盖了会儿,,锁屏突然推送了广告,这几个字,读了好几遍,好是喜欢。耳机刚好播放到最近很是喜欢的《你的酒馆对我打了样》,我调整了椅子,时速307km逃离着这座有你的城市。

杭州高楼鳞次栉比,穿过一栋栋高楼就来到了绍兴,这个城市不是很繁华,倒也是一个保留的很好的江南古镇,我很喜欢这里,火车站,背着包,司机师傅操着一口流畅的普通话礼貌的问着我去哪儿,一边介绍着风景名胜,满满的都是对这个城市的热爱,有风景名胜兰亭,壮阔的东湖,一个慢节奏的小城市,除却了对金钱的渴望,连揽客都变得那么悠闲。

吃过饭,和侄子一起去了仓桥直街,其实可以理解为低配版的南锣鼓巷,人不算特别多吧,但是风景却很好的保留了江南的风味,一轮明月(非p30pro),以及灯光的烘托,让江南的夜晚,似乎比白天更加的夺目。陈旧的街巷保留了最初的最原始的石板街,街边的店家还是很古旧的撑着旗帜,还是过去那种一个很大的门(2m高*7个木板)还有很多过去的宣传标语,当然也有很多小吃。

第二天的行程主要就是鲁迅故居了,其实并没有什么让我眼前一亮的地方,因为这里的人实在太多了,我早上九点半抵达景点,到11点才排队进入了鲁迅祖居,倒也很是沮丧,而且祖居里其实并没有什么值得参考的,游人们看长安花一样,参观者一个一个的房间。然后我又排队了40分钟进入了百草园,想一看鲁迅童年最快乐的地方,但却也什么也没有看到,一个不是很好看的花园,料理的和我爷爷的菜地一样,不过或许树人童年就是在这么一块地方进行玩耍的,很多游人围着百草园的一块大石头上合影留恋,排着队,各种姿势摆拍,令我觉得很是不舒服(我也没有拍到)。

鲁迅祖居

鲁迅祖居

百草园一角

倒也怎么看,鲁迅的童年应该也很是无聊,强行找着自己的乐子吧,后来排了30分钟的队伍去了三味书屋,其实我当时的心情是抗拒的,但还是忍着烈日,走上了不归的队伍,书屋的景点其实很小,一个小的教室,两边是家长的坐席,中间是学生的座位,图片可以看到鲁迅其实是坐在讲台左边的,看来他小时候也是个先生特别关照的对象鸭。

三味书屋

其实每逛完一个景点都是非常长的商业街,路的两边充斥着特产豆腐,黄酒产品,虽然我不是很反感这种景点恰饭情景,但是满街飘着臭豆腐的味道,回荡在鲁迅故居的上空,但多少也是有点违和,第二天的行程是安昌古镇,其实也没有什么特别的。

IMG_20190503_122634

历史的前轮碾压而过,很多东西都因为商业化而丢失了曾经的自己,不过总体来讲我还是比较喜欢吃过午饭,在江南的水边走着,遇到一位94岁的奶奶晒太阳,打了个招呼,他居住在这里三十年了,每次节假日,这里都会来很多人,之前就在这河里洗衣服,打水,后来腿脚不方便了,就搬把凳子坐在这里,听着繁华的声音,晒着太阳,看着船夫送走一个又一个人,这里的瓦年龄都很大,之前屋子的瓦还坏过一个,他折腾了好久才暂时不滴水了,她涛涛不觉的讲着,沉醉在这个小镇带给他的快乐和烦恼中

两天的行程不是很满,不是很累,也不是很轻松(到哪儿,哪儿都排队),回去没有抢到票,从绍兴一直站着回了北京,小说确实也没有读的下去,我看着窗外的风景,思念着一个人,认识这么久,我还没和你一起旅游过

Introducing Node.js 12

raw article

Apr 24

This blog was written by Bethany Griggs and Michael Dawson, with additional contributions from the Node.js Release Team and Technical Steering committee.

We are excited to announce Node.js 12 today. Highlighted updates and features include faster startup and better default heap limits, updates to V8, TLS, llhttp, new features including diagnostic report, bundled heap dump capability and updates to Worker Threads, N-API and ES6 module support and more. The Node.js 12 release replaces version 11 in our current release line. The Node.js release line will become a Node.js Long Term Support (LTS) release in Oct 2019 (more details on LTS strategy here).

V8 Gets an Upgrade: V8 update to V8 7.4As always a new version of the V8 JavaScript engine brings performance tweaks and improvements as well as keeping Node.js up with the ongoing improvements in the language and runtime. Highlights include:

Read more about V8 at their official blog.

Hello TLS 1.3

Node.js 12 is introducing TLS1.3 support and making it the default max protocol, while also supporting CLI/NODE_OPTIONS switches to disable it if necessary.

TLS1.3 is a major update to the TLS protocol, with many security enhancements and should be used over TLS1.2 whenever possible.

TLS1.3 is different enough that even though the OpenSSL APIs are technically API/ABI compatible when TLS1.3 is negotiated, changes in the timing of protocol records and of callbacks broke assumptions hard-coded into the ‘tls’ module. This change introduces no API incompatibilities when TLS1.2 is negotiated. It is the intention that it be backported to current and LTS release lines with the default maximum TLS protocol reset to ‘TLSv1.2’. This will allow users of those lines to explicitly enable TLS1.3 if they want. If you want to read more you can check out these related articles:https://developer.ibm.com/blogs/openssl-111-has-landed-in-nodejs-master-and-why-its-important-for-nodejs-lts-releases/, https://developer.ibm.com/blogs/tls13-is-coming-to-nodejs/

Properly configure default heap limitsThis update will configure the JavaScript heap size based on available memory instead of using defaults that were set by V8 for use with browsers. In previous releases, unless configured, V8 defaulted to limiting the max heap size to 700 MB or 1400MB on 32 and 64-bit platforms respectively. Configuring the heap size based on available memory ensures that Node.js does not try to use more memory than is available and terminating when its memory is exhausted.

This is particularly useful when processing large data-sets. As before, it will still be possible to set — max-old-space-size to use a different limit if the default is not appropriate for your application.

Switch default http parser to llhttp
Node.js 12 will also switch the default parser to llhttp. This will be beneficial in that it will make testing and comparing the new llhttp-based implementation easier. First introduced as llhttp experimental in v11.2.0, llhttp will be taken out of experimental in this release.

Making Native Modules Easier — progress continuesNode.js 12 continues the trend of making building and supporting native modules easier. Changes include better support for native modules in combination with Worker threads, as well as N-API (https://nodejs.org/api/n-api.html#n_api_n_api) version 4 (which has also been backported to 8.x and 10.x) which makes it easier to use your own threads for native asynchronous functions. You can read more about this and how you can leverage it in your modules in this great article here: https://medium.com/the-node-js-collection/new-features-bring-native-add-ons-close-to-being-on-par-with-js-modules-cd4f9b8e4b4

Worker ThreadsWorker Threads (https://nodejs.org/api/worker_threads.html), while not new in this release, are still seeing progress. The use of Workers Threads no longer requires the use of a flag and they are progressing well towards moving out of experimental. While Node.js already performs well with the single-threaded event loop, there are some use-cases where additional threads can be leveraged for better results. We’d like you to try them out and let us know what use cases you have where they are helpful. For a quick introduction check out this great article: https://medium.com/@Trott/using-worker-threads-in-node-js-80494136dbb6.

Diagnostic ReportsNode.js 12 brings with it a new experimental feature “Diagnostic report.” This allows you to generate a report on demand or when certain events occur. This report contains information that can be useful to help diagnose problems in production including crashes, slow performance, memory leaks, high CPU usage, unexpected errors and more. You can read more about it in this great article: https://medium.com/the-node-js-collection/easily-identify-problems-in-node-js-applications-with-diagnostic-report-dc82370d8029.

Heap DumpsIf you ever needed to generate heap dumps in order to investigate memory issues but were slowed down by having to install a new module into production, the good news is that Node.js 12 brings integrated heap dump capability out of the box. You can check out the documentation in https://github.com/nodejs/node/pull/27133 and https://github.com/nodejs/node/pull/26501 to learn more.

Startup ImprovementsIn Node.js 11 we shipped built-in code cache support in workers — when loading built-in libraries written in JavaScript, if the library was previously compiled on the main thread, the worker thread no longer needs to compile it from scratch but can reuse the v8 code cache generated by the main thread to speed up compilation. Similarly, the main thread can reuse the cache generated by workers. This gave a roughly 60% speedup for the startup of workers.

Now in Node.js 12 we generate the code cache for built-in libraries in advance at build time, and embed it in the binary, so in the final release, the main thread can use the code cache to start up the initial load of any built-in library written in JavaScript. This gives a ~30% speedup in startup time for the main thread.

ES6 Module SupportNode.js 12 brings an updated experimental version of support for ES6 modules. It is an important step toward a supported implementation and we’d like you to try it out and give us feedback. For more details check out this great blog post.

New compiler and platform minimumsNode.js and V8 continue to embrace newer C++ features and take advantage of newer compiler optimizations and security enhancements. With the release of Node.js 12, the codebase now requires a minimum of GCC 6 and glibc 2.17 on platforms other than macOS and Windows. Binaries released at Node.js org use this new toolchain minimum and therefore include new compile-time performance and security enhancements.

The increment in minimum compiler and libc requirements also increments minimums in supported platforms. Platforms using glibc (most platforms other than macOS and Windows) must now include a minimum version of 2.17. Common Linux platforms compatible with this version include Enterprise Linux 7 (RHEL and CentOS), Debian 8 and Ubuntu 14.04. Binaries available from nodejs.org will be compatible with these systems. Users needing to compile their own binaries on systems not natively supporting GCC 6 may need to use a custom toolchain. Even though Node.js 12.0.0 may compile with older compilers, expect the Node.js 12 codebase (including V8) to rapidly adopt C++ features supported by GCC 6 during the pre-LTS timeframe.

Windows minimums remain the same as Node.js 11, requiring at least Windows 7, 2008 R2 or 2012 R2 and a minimum compiler of Visual Studio 2017. macOS users needing to compile Node.js will require a minimum of Xcode 8 and Node.js binaries made available on nodejs.org will only support a minimum of macOS 10.10 “Yosemite”.

Further details are available in the Node.js BUILDING.md.

**Thank you!**A big thank you to everyone who made this release come together, whether you submitted a pull request, helped with our benchmarking efforts, or you were in charge of one of the release versions. We’d also like to thank the Node.js Build Working Group for ensuring we have the infrastructure to create and test releases. The release manager for Node.js 12 is Bethany Griggs. For a full list of the release team members head here. You can read more about the complete list of features here.

If you are interested in contributing to Node.js, we welcome you. Learn more via our contributor guidelines.

快要毕业了,朋友圈里洋溢着,毕业的快乐,直系学弟们也返校进行了毕业论文的最终答辩,也希望他们都取得一个好的成绩,能在回首大学四年时候,不因为碌碌无为而后悔,能够在社一中,找到一份合适的工作,并感谢曾经那个在大学奋斗的自己。

毕业季第一道坎就是租房(家里有矿的,这篇文章你就可以关掉了),总体来说,在京就业,房租确实很贵的,不过对于计算机专业来说,应该还是可以的。我们熟知的计算机区域

  • 望京SOHO(小企业居多)
  • 中关村
  • 中关村软件园(大厂)

对应的租房地点可以选择:

  • 孙河(就可能地铁站远一点)
  • 上地附近
  • 回龙观,朱辛庄

主要平台(按推荐顺序):

  • 自如(个人选择项,应届生有特权)
  • 豆瓣小组
  • 闲鱼
  • 相如>蛋壳=贝壳

应届生可能囊中羞涩,所以建议选择自如,分期月付(应届免押金,分起费120附近),不过计算机专业的应届生薪资理论上是>=7k,所以我觉得应该马马虎虎可以生存下来了。之所以不推荐其他的中介,是因为你可能租房后,对于维修,舍友抽烟,养的宠物半夜狂叫,又退不了租,陷入麻烦中。(自如麻烦来结一下广告费)

另外整理一下招聘的软件(按推荐顺序):

  • (个人软件工程,仅供参考)

  • BOSS

  • 拉钩

  • 智联招聘

  • 脉脉

希望这些资料对刚毕业的你有所帮助,其余想起来的,再直接更新

经历了连续9*13小时的工作后,我终于得到了一天的调休计划,昨晚十一点半打车从五棵松到家

洗了个热水澡,关了手机闹铃,打开了Alexa的环境噪音,难的踏实的进入了梦中。

但是!!

我Alexa的闹钟忘记关了,七点被吵醒后一直没有睡着,所以起床热了杯牛奶,弄了张煎饼,涂了点番茄酱就凑合吃了,后来外出和朋友聊了会儿天,倒确实点出了一些目前存在的问题

  • 一个好的技术不仅要知其然,更要知其所以然,多挖掘他背后的源码,去思考如何实现,这样才能在高并发时,将200ms优化到100ms,才是一个高级程序员应该具备的素质之一
  • Node学习分为三年,第一年知其语法,会写应用,第二年知其框架,高级开发,第三年,读其源码,知其原理
  • 多用语言去写一些工具类,多去学习和参考优质轮子,而不是写一些玩具,别人都写烂的东西
  • (重要的应该就这么多了)

朋友的话很对,我也进行了思考,自己在JS的道路上,摸着黑走路,对于源码其实要读,但是之前打开看过一眼就一脸懵逼的状态,所以还是需要有时间学习一下优质的GitHub,撕开一个口子,然后进入到正轨,自己去多写一些方法区调用,然后一点点去琢磨,他的实现过程。

4月底的计划就是

  • 尽量换一份工作,受不了8117,薪资还不如麦当劳的临时工
  • 自如租约到期了,搬家到朱辛庄或者霍营
  • 没换工作的话,买一本书通勤看会儿,换工作的话,抽个零碎的时间读,顺便整理笔记,更博(暂定这个月读一下v8的gc)
  • 五一出去旅游,暂时想去杭州看看
  • 买点竹筒,想做竹筒饭

自今日起,博客开始停更

996.icu

年后开始,互联网似乎过得都不好,从七陌被裁(也有个人原因吧),到被航天二院,知网,中电科因为学历卡住入职(BOSS直聘,面试完了,技术找人事审核不通过),后来遇到了一系列傲慢的中科软系列面试,无限加班的创业公司,还有那种以培训机构为目标招人的小公司。最终未能收获一个满意的offer,最终舔狗选择了一家说是不加班的某所,然,现在才发现,实在太忙,包括现在也刚刚到家,工作也没有pc,没有网络,所以也很不方便随时学习,可能有一些手写笔记,但经历有限,所以最近会停止更新

年后996冲上了榜首,让世界都在反思为什么中国的加班为什么如此疯狂,但话题热度很快下降,因为没有人会去放下手中的工作去抵制,毕竟生活总要继续下去

生活总是这样,起起落落落

努力不一定有回报,但不努力一定很(mei)舒(hui)服(bao)

晚安~hexo

Problem

The set [1,2,3,...,*n*] contains a total of n! unique permutations.

By listing and labeling all of the permutations in order, we get the following sequence for n = 3:

  1. "123"
  2. "132"
  3. "213"
  4. "231"
  5. "312"
  6. "321"

Given n and k, return the kth permutation sequence.

Note:

  • Given n will be between 1 and 9 inclusive.
  • Given k will be between 1 and n! inclusive.

Example 1:

1
2
Input: n = 3, k = 3
Output: "213"

Example 2:

1
2
Input: n = 4, k = 9
Output: "2314"

key

solution

perfect

what

advantage

客户端在使用HTTPS方式与Web服务器通信时有以下几个步骤,如图所示。

  (1)客户使用https的URL访问Web服务器,要求与Web服务器建立SSL连接。

  (2)Web服务器收到客户端请求后,会将网站的证书信息(证书中包含公钥)传送一份给客户端。

  (3)客户端的浏览器与Web服务器开始协商SSL连接的安全等级,也就是信息加密的等级。

  (4)客户端的浏览器根据双方同意的安全等级,建立会话密钥,然后利用网站的公钥将会话密钥加密,并传送给网站。

  (5)Web服务器利用自己的私钥解密出会话密钥。

  (6)Web服务器利用会话密钥加密与客户端之间的通信。

problem

Given a positive integer n, generate a square matrix filled with elements from 1 to n2 in spiral order.

Example:

1
2
3
4
5
6
7
>Input: 3
>Output:
>[
[ 1, 2, 3 ],
[ 8, 9, 4 ],
[ 7, 6, 5 ]
>]

key

虽然标了medium,但是确实很简单,形成一个口字型闭环,一层层去处理就好了,然后再主要就是控制口字循环时候的边界,以及最后一个元素的判断

solution

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
public int[][] generateMatrix(int n) {
int [][]res = new int[n][n];
int left = 0;
int right = n-1;
int top = 0;
int bottom = n-1;
int index = 1;
int quit = n*n;
while(index<=quit){
for(int i=left;i<=right;i++) {
res[top][i] = (index++);
}
top++;
for(int i=top;i<=bottom;i++){
res[i][right] = (index++);
}
right--;
for(int i=right;i>=left;i--) {
res[bottom][i]=(index++);
}
bottom--;
for(int i=bottom;i>=top;i--) {
res[i][left]=(index++);
}
left++;
}
return res;
}

perfect

no

0%