掘金技术征文 | 【我与那个开发库 / 框架的爱恨情仇】评选结果

by admin on 2018年12月17日

正文

二等奖

1.
匪去个车轱辘,你还当真觉得你会师写代码了?

前端框架 Vue.js 在 2016 年可谓势头正劲,火了平等拿。本文开发者
@qieguo
也以镂 Vue 实现原理的长河被去了单「轮子」,将 Vue
的绑定指令基本落实了同不折不扣,可以望,开发者本身对技术为来于实在的明白与行使。

2. 暴发几乎独基类, 用 Dagger 注入多少个工具类就敢为 MVP + Dagger
框架?

MVPArms 是一个构成了大量主流开源项目之 Android MVP 急忙搭建框架,其中蕴藏
Dagger2Retrofit、Rxjava 以及 Rxbinding、RxCache 等 Rx
系第三方库,并且提供 UI 自适应方案。MVPArms 将它们组成起来,并尽应用
Dagger2 管理并提供给开发者使用。开发者
@jessyan
更是注脚会提供合维护和迭代成本,相信可以针对而的 Android
项目开发有助。

3. underscore
源码分析

正文针对强的 JavaScript 函数式编程库 underscore
进行了老周详而详细的辨析,更是对这源及计划思路举办了深入之探索,相信就篇稿子能成
JS 开发者函数式编程的入门手段与 JS 进阶的跳板。

停放技能

点分治(这不是要学动态点分治吗)

线段树(会触发分治不会师线段树?)

实质上线段树是来助了然的。

 

通过慎重的审批和评选,我们吧起入活动参预条件的著述中摘出了这一次征文活动的
14 名获奖者,名单如下:

引入

接触分治是一致种人人爱好的算法。它含钙高,吸收好动脑筋相比简单,代码实现啊无麻烦,复杂度瓶颈在总结跨重心root的链对答案的熏陶/贡献。

而点分治的败笔是丰富引人注目标:它不得不开离线问题!换句话说,它不帮助修改操作。

斯时便得动态点分治来救助拉了。  

 

三等奖(阅读量最高 10 首著作)

  1. 知情谈高大上的图片加载框架 Glide –
    源码篇
  2. 掘金:网络框架分析 –
    全是套路
  3. 掘金:项目举行快,全靠 iView
  4. 掘金:Vuex 实战:如何在广大 Vue 应用中集体 Vuex
    代码
  5. 掘金:iOS
    实现长足切换主旨详细教程(附上源码)
  6. 「神兵利器Dagger 2 | 掘金技术征文
  7. 掘金: transformjs 污染了 DOM?
    是若莫打听其的雄强
  8. 掘金:通过项目渐渐深入驾驭Spring
    MVC(一)
  9. 掘金:Spring Boot 揭秘与实战(五) 服务器篇 – 内嵌的服务器
    汤姆cat剖析
  10. 掘金:信息队列之异步音讯之基本概念以及ActiveMQ整合Spring的常用用法介绍

图片 1

如上就是是率先意在掘金技术征文活动的得奖名单,请上述作品的受奖作者耐心等待,大家会经稀土君微信号(ID:xitujun)即常常跟诸位取得联络。

当然,没有获奖的诸位也未用凉,每一样篇与运动的随笔还十分雅观,希望各位开发者们可以当连接下去的倒中延续腾插足。

侃两句子淡

为什么被入门随讲也……因为自啊恰恰学完什么

 

历时半单多月,第一期望掘金技术征文大旨活动终于赢得下了帐篷。短短半独月之时空里,我们也跟豪门一起,见证了掘金上各位开发者的技术实力,也感受及了掘金上厚的技巧氛围,更触及到了开等技术外的别样一样迎。

啊好友于广告(利用好友卓绝博文提高×格)

句句经典……在点分上一直不必然造诣还确实写不出去。

墙裂推荐一观,文笔和揣摩都相比较有hr好多了。

泛泛谈对碰分治的一对清楚——qt666

 

一等奖

从而 React、Redux、Immutable
做俄罗丝方

俄联邦(Rose)方块是直接各个程序语言热衷实现之经典游戏,JavsScript的贯彻版本为生为数不少,用React
做好俄罗丝(Rose)方块则变为了开发者
@Chvin
的一个靶。

尽管是一个练手应用,Chvin将俄罗丝(Rose)方块的感受完了足好,应用本身吗够有趣,在掘金拿到了相当大的收藏量与评论,一等奖可谓实至名归。

恭喜
@Chvin
得到由掘金提供的 1000 元现金奖励。

最终为送一样点套路

少数触及lca什么的别用倍增了,用欧拉连串+ST表预处理O(1)搞定。

还有记得将log也先期处理下,系统超慢。

开堆开桶之类的,vector或new

算法原理

这些时节大家曾经对点分治的通晓好怪了。它通过巧妙地以k级重心处划分,把树上的门路划分成了点滴近乎:经过重心的以及免通过重心的。

从而复杂度有保,是以每个点当链端点只会于总结log不良。

拉动修改的语,暴力肯定是探听同不佳召开同不佳接触分。

顾到修改的着力是点权之类的要不是塑造的模样。换言之,每一趟的点分过程是同的!

下一场又想到每个点才会师让计算log软——胡不重构这树乎?

谈清楚点:既然每一遍修改才会转一个触及,只相会管其当作端点的链的音信改掉。

(尽管你改变一个接触碰面挑起三个点转呢未像是树分治题而再如风数据结构题)

旁的触发之音该是多少如故稍微,是勿更换的来往,是永恒之黑暗及孤单——打住。

往往甩卖又同一消息,是一定非可能吃大家所称道的。而那多少个音讯到底的数据级以只来O(nlogn)级别。

为啥非把它们先保存,然后于每便修改,O(logn)级别地暴力一一修改为?

老是查询,要么直接拿走,要么暴力跳一个触及的重心祖先链,复杂度也分外美好。

固然:预处理点分治一满,把各自重心树将出来,把信存上。

历次操作,修改就想方改好及祖先重心链上之音即可。

打探呢,你还维护了如此多东西了,也是回忆艺术神速求即得了。

本说取最酷价值,这便开堆嘛(ZJOI捉迷藏)。

再也比如说HNOI开店,用vector动态申请空间,排序一下,每一遍询问暴跳祖先。

说起来好像死简单,实现起来然则如人饮水冷暖自知。

 

余下的自身一世吗无明了仍能讲啊了?……

送一样词话:树上的动态点分治就相当给队列及之线条树。

遗忘是起哪个神犇这蒯的了……

 

发表评论

电子邮件地址不会被公开。 必填项已用*标注

网站地图xml地图