痛苦之路

发表于 2018-08-05 | 分类于随笔

”想要见到尘封的秘密，就要承受最严厉的惩罚” —— 痛苦之路 · 题记

这是《空洞骑士》（Hollow Knight）中最为艰难的一段路，终于用了8个小时的时间，走完了全程。这不像一份成就，反而更像是一次修炼，一场旅程

委婉而悲伤的曲调和电锯旋转的声音还在脑海中回荡，但早已不记得当初为什么要踏上这条道路，一条毫无容错率的道路。也许是为了挑战，挑战制作组的恶意，见识一下让论坛上一个个大神都痛不欲生的“快乐之路”，也许只是为了一种虚无的成就感

游戏的色调是黑白的，游戏的主角也是黑白的，如果真的会留下血渍的话，那恐怕电锯和荆棘早已染成一片通红，一次又一次的跌倒在同一个地方，用生命与时间在尝试

“道理我都懂，但我真的做不到”

在每一个时间点要做什么事情我都清楚，但我的手速跟不上，亦或是精神不够集中，也可能那根本就是不可能的，我的想法是错的。我不清楚，迷茫的时候就去看看大神的视频攻略，看看别人是怎么用4分钟走完的

所以这里为什么叫做痛苦之路呢，真正的痛苦又来源于何方呢？

我卡在一个荆棘遍布的房间里，一个小时过去了，我依然站在那里，空洞骑士雕像的旁边，一个小时里我做了各种的尝试与努力，但我依然完成不了一个简单的 下劈+冲刺+二段跳+下劈 的组合操作，而更为沮丧的是我总死在做这个操作前的路途上，从哪里跌倒就从哪里爬起来该是多美好的事情啊

要不还是放弃吧，面对已经在颤抖的左手无名指，太多次的跳跃操作已经嚷它麻木了。但想一想之前的努力怎么办，一路辛苦的走过来，在前面再有三个落脚点就可以到结局了，为什么要在这里停下，前面的坎没有什么，大神都过去了，我只要保证在路途上少犯错创造更多的尝试机会就好了

集中精神，向前看，尽量不在跌倒过的地方再犯错

想的好容易啊，等完成了它之后我就可以在别人面前显摆了呀，糟糕，又跳大了，下劈又没有劈出来，不行，还要继续集中精神。不过别人根本不会关心你的，他们不知道你在这条道路上有过多少磨难，即使他们称赞了你，那又能怎样，是真心的么？还是说这一切只是为了自己的一份虚荣呢？这不是虚荣，已经死成这个样子了也没有什么可显摆的，只是因为看别人可以过去所以我才可以过去，我没有比别人差。难道说这一切的痛苦都是来源于想要得到对自己的认同感么

自我的认同感——好虚幻的东西，那获得了自我的认同感，就能获得快乐了么？所以能活在自己的小世界里面，能对自己认同，会是很快乐的事情呀。这份快乐真实么？一定真实，因为快乐本来就是内心的产物，而自我的认同也是内心的感受。所以接下来放松心态就可以过关了呀，因为我不再是为了取悦别人去做什么，而是为了自己的满足感，这是一场自我的试炼，我能想象功成名就的样子，放下了心里的包袱，感觉左手无名指的感觉又回来了

为了自己的满足感——自私的想法，毕竟这是个社会，而不是一个人自闭的世界，那认同感的快乐设定能否被继续套用呢？如果一个人认同了自己会获得快乐，那两个人彼此认同是否也能获得快乐呢？奇怪而又大胆的想法，人生路走了那么久，遇到过太多不认同的事情，也有过太多的痛苦

最后一个房间我卡了2个多小时，以至于当最后一刻到来时，当所有喜悦冲倒懊丧感的时候，我依然能准确的复述出这个房间的流程，在什么时刻出发，在什么时间跳跃，在每一个齿轮上下劈几下。而错过的晚饭，渴求被安慰的心理，在同一个地方失足的挫败与懊丧，也总会随着时间慢慢淡去

Reference

https://www.bilibili.com/video/av15410552/?p=6

“人生是一场华丽的冒险，也是一场痛苦的旅程”

“道理我都懂，但我真的做不到”

“没人想倒在同一个地方，相信我”

“如果凡事都是能从哪里跌倒就从哪里爬起来，该是多美好的事情啊”

“梦想很美，但我真的有心无力”

“如果世间所有第一切都像游戏一样有着快速而鲜明的反馈就好了”

“什么时候能像玩游戏一样做事情，思路清晰，心无旁骛”

“生命中没有那么多东西需要背负”

“都说行百里者半九十，但九十的时候也得有个里程碑标识一下呀”

“你坚持的事情可能在别人眼中根本微不足道，要学会放弃”

“你坚持的事情可能在别人眼中根本微不足道，但对于你来说，那也许就是一切”

“没有痛苦，就没有快乐”

绿水青山图

发表于 2018-06-07 | 分类于随笔

绿水青山图，听起来挺诗情画意的名字，在2018年的考场上，出现的也真是残酷。

好在今天的天气还不错，看来你依旧安好，六月七日——晴天。一大早出门时，背后是高照艳阳，前一天刚下过雨，晒而不热，暖风拂面，晴空万里。等到中午的时候，白云开始任意翻卷成各种形状，坐在窗边，怀念着初中时躺着操场上遐想的时间。傍晚的云已经积累成雨，准备着再次回归到这大地。看得出，明天还会是一个好天气。

如果每天都是这样该有多好，没有绿水没有青山，只求蓝天一片，白云朵朵，足矣。

青山早已变成楼房，绿水也早已成为缓缓的车流。但我仍想大口畅快的呼吸，在田野间奔跑，在山间呐喊，等待着自己的回声，那是大自然给我的回信，一遍又一遍，在苍穹之间，我呼吸着他的气息。流水潺潺，清澈透明，捧在手里是蓝天的颜色，流在山间是草木的颜色，那叮咚的旋律，是大自然最沁人的图案。

飞鸟掠过，把我留在楼宇之间，此刻，我只听到了发动机的轰鸣。看着它的远去，我望着长空，坠落。

不知道是不是每个人都曾经有过这样一个梦，我相信都有过的，只是有些人忘记了。绿水，青山，独木桥，桥的这一端是砖瓦垒砌的小村庄，那一头是山路。那是我还小，在村里玩耍，小孩子都很贪玩，一转眼妈妈就不见了，我慌张的四处寻找，最后只看到了她的背影。那时我在独木桥的这一头，她在桥上缓缓往那边走去，一身纯洁的白纱，在水面上打出倒影，美到窒息，美到我傻傻的站在那里忘记前行，或者说不愿也不敢去破坏这一副山水画。就这么看着她远去，最终消失在路的尽头，绿树环绕的地方。然后惊醒。至今，我的心还在那个小村庄里游荡，等着她回来，为自己的贪玩向她道歉，但她却再也没有回来，再也没有在我的梦中出现，再也没有。

看到绿水青山图这个名字，莫名就想起了她，我想我不应该再等待了，我要去追赶她的步伐，离开这座让我贪玩的小村庄，去追求我的向往。去大山的深处，自由自在的生活，追逐山间的回响，倾听流水的旋律，闻着花香，数着飞鸟。那里才是我的归宿。

梦醒来，我还在小村庄里，在2018年的高考考场上，蓝天白云孩子，但通往大山的独木桥，在日渐浑浊的水面上渐渐消失。我现在桥的这头，眼前的一切，慢慢凝结成一幅青山绿水图。

困了困了，结尾写得可能太悲伤了，还是不要发生的好。保住眼前的蓝天白云，终有一日我们能走过独木桥，回归大自然的青山绿水之间

Slice Append Trap in Golang

发表于 2018-05-22 | 分类于 Golang

最近再用没事的时间刷leetcode，顺便学习一下Golang的简单语法，然后就被坑了。。。

今天遇到的题目是 #46-Permutations

Given a collection of distinct integers, return all possible permutations.

Example:

Input: [1,2,3]
Output:
[
  [1,2,3],
  [1,3,2],
  [2,1,3],
  [2,3,1],
  [3,1,2],
  [3,2,1]
]

题目应该来说比较常规啦，没什么算法可言，输出就是 n! 了，就拿笨办法做吧，于是就有了下面我的code，非常无脑的反复堆叠数组

func permute(nums []int) [][]int {
    var ret,hold [][]int
    for _,v := range nums {
        hold = append(hold, []int{v})
    }
    for i := 1; i < len(nums); i++ {
        for _,arr := range hold {
            for _,v := range nums {
                flag := true
                for _,a := range arr {
                    if a == v {
                        flag = false
                        break
                    }
                }
                if flag {
                    ret = append(ret, append(arr,v))
                }
            }
        }
        hold = ret
        ret = make([][]int, 0)
    }
    return hold
}

本来以为是辣么简单的逻辑，然而。。。竟然出现了wrong answer…

你可以说我run time error，你可以说我time limit，但是为什么会有wrong answer…

Input:
[6,3,2,7,4,-1]
Output:
[[6,3,2,-1,7,4],[6,3,2,-1,4,7],[6,3,2,-1,7,4],[6,3,2,-1,4,7],...
Expected:
[[6,3,2,7,4,-1],[6,3,2,7,-1,4],[6,3,2,4,7,-1],[6,3,2,4,-1,7],...

看起来好像是顺序问题，但仔细一看Output的前两个元素一毛一样啊ヽ(*。>Д<)o゜

吐了好几摊血之后，有了下面一段debug记录

func permute(nums []int) [][]int {
    var ret,hold [][]int
    for _,v := range nums {
        hold = append(hold, []int{v})
    }
    for i := 1; i < len(nums); i++ {
        for _,arr := range hold {
            for _,v := range nums {
                fmt.Println(1,ret) // #1
                flag := true
                for _,a := range arr {
                    if a == v {
                        flag = false
                        break
                    }
                }
                if flag {
                    fmt.Println(2,ret) // #2
                    a := append(arr,v)
                    fmt.Println(3,ret) // #3
                    ret = append(ret, a)
                    fmt.Println(4,ret) // #4
                }
            }
        }
        hold = ret
        ret = make([][]int, 0)
    }
    return hold
}

// Output 节选，前面的都对，不要问为什么
1 []
1 []
1 []
1 []
2 []
3 []
4 [[1 2 3 4]]
1 [[1 2 3 4]]
2 [[1 2 3 4]]
3 [[1 2 3 5]]  // <-
4 [[1 2 3 5] [1 2 3 5]]

作为一个相信科学的小码农，我第一次感到了来自未知世界的恶意，#2 和 #3 之间的操作可以说与数组ret完全没有关系，然而，ret的值，变了。。。没错，当len(arr)=2的时候没有变，当len(arr)=4的时候没有变，而在len(arr)=3的时候，变了。

本着Geek精神，又加了点料，打印了ret和中间量a的地址

func permute(nums []int) [][]int {
    var ret,hold [][]int
    for _,v := range nums {
        hold = append(hold, []int{v})
    }
    for i := 1; i < len(nums); i++ {
        for _,arr := range hold {
            for _,v := range nums {
                fmt.Printf("%p ",ret)
                fmt.Println(1,ret)
                flag := true
                for _,a := range arr {
                    if a == v {
                        flag = false
                        break
                    }
                }
                if flag {
                    fmt.Printf("%p ",ret)
                    fmt.Println(2,ret)
                    a := append(arr,v)
                    fmt.Printf("%p %p ",ret, a)
                    fmt.Println(3,ret)

                    ret = append(ret, a)
                    fmt.Printf("%p %p ",ret, a)
                    fmt.Println(4,ret)
                }
            }
        }
        hold = ret
        ret = make([][]int, 0)
    }
    return hold
}
// Output - 没有错误的地方
0x1953e4 1 []
0x1953e4 2 []
0x1953e4 0x10415ae0 3 []
0x10462220 0x10415ae0 4 [[1 2 3]]
0x10462220 1 [[1 2 3]]
0x10462220 2 [[1 2 3]]
0x10462220 0x10415b20 3 [[1 2 3]]
0x10448280 0x10415b20 4 [[1 2 3] [1 2 4]]
// Output - 出错的地方
0x1953e4 1 []
0x1953e4 2 []
0x1953e4 0x10415ae0 3 []
0x104a3610 0x10415ae0 4 [[1 2 3 4]] // <-前一个循环
0x104a3610 1 [[1 2 3 4]]
0x104a3610 2 [[1 2 3 4]]
0x104a3610 0x10415ae0 3 [[1 2 3 5]] // <-后一个循环
0x104482a0 0x10415ae0 4 [[1 2 3 5] [1 2 3 5]]

在没有出错的地方，每一次临时变量a的地址都是会变动的，而在出错的地方，第二次声明临时量a的时候地址没有发生变化，很显然ret还在引用着这个地址，于是后一次的更新直接导致ret的改变。简直就像是恐怖片。。。

网上查了一些资料（见reference吧），Golang的slice有自己的优化方式。而从我们遇到的问题来解释，事实上呢，0x10415ae0——这个地址就是此时arr的地址，不用说此时arr的cap肯定还有富余，底层在执行append的时候就偷懒没有去申请新的地址，于是就悲剧了

关于slice的cap是怎么分配的，做了一个试验

var a []int
for i:=0;i<100;i++ {
    a = append(a,1)
    fmt.Println(cap(a),a)
}
// Output
2 [1]
2 [1 1]
4 [1 1 1]
4 [1 1 1 1]
8 [1 1 1 1 1]
8 [1 1 1 1 1 1]
8 [1 1 1 1 1 1 1]
8 [1 1 1 1 1 1 1 1]
16 [1 1 1 1 1 1 1 1 1]
16 [1 1 1 1 1 1 1 1 1 1]
16 [1 1 1 1 1 1 1 1 1 1 1]

结论应该显而易见了，而对于怎么修正 #46-Permutations 的solution，在此也就不赘述了

Reference

leetcode: https://leetcode.com/
Golang：slice之append时原数组发生变化的问题:
https://blog.csdn.net/books1958/article/details/46931127
对GoLang里的slice要谨慎使用append操作:
https://blog.csdn.net/gzliudan/article/details/23515381

人到中年，整个一部西游记！悟空的压力，八戒的身材，老沙的发型，唐僧一样絮絮叨叨！还特么的离西天越来越近了[捂脸]

JavaScript的‘故’事

发表于 2018-04-11 | 分类于杂谈

上帝创造世界用了七天时间，上帝想毁灭世界，于是有了JavaScript

很多人诟病JavaScript，描述为审判日的预兆，但JS究竟做了什么，会被黑的如此惨烈呢，作为一个重度使用JS的入门玩家，简单做了一些调查，今天的话题也是从这里开始的

JavaScript的原型是1995年由Netscape公司的Brendan Eich所开发的程序设计语言LiveScript，其本意也是为了能给当时如同报纸一样死板的HTML注入一些生命与活力。后来Netscape 2.0发布之后，正式更名为JavaScript。

再后来竞争对手Microsoft看着眼红，发布了支持JScript的IE 3.0。JScript呢，基本上就是就是JavaScript的翻版，就好像C#对于Java的样子，而且还引入了一些IE独有的特性。

后来大家觉得这么下去不是个事，为了使语言的实现更趋向于标准化，ECMA(European Computer Manufacturers Association)建立了ECMAScript，也就是大名鼎鼎的ES，同时创建了ECMA-262标准，该标准脱离了浏览器和那些Web独有的特性，集中描述了JavaScript作为编程语言的核心部分。

迄今为止，ECMA-262已经有了N多的版本，也从最开始的编号，演变成现在的按照年份编号。目前就我来说接触比较多的是ES5和ES6了

而JS真正成是在1996年到2001年的第一波互联网热潮中。当时Netscape和Microsoft都在争夺浏览器的制霸权，疯狂的进行浏览器的版本演化，不断给其增加各种浮夸的特性，却忽略了对于开发工具JS的更新。伴随着无穷无尽的兼容性问题，在那个连高亮JS关键字的文本编辑器都没有的年代，开发JS的痛苦可想而知。另一方面，浏览器的用户体验也十分捉急。内忧外患之下，JS的声誉也是一损再损。

第一次浏览器大战的结局相比大家都清楚，MS最终以IE6平定了天下，然而讽刺的是IE6也成为了所有前端开发挥之不散的噩梦。

好在后来MS后来放松了警惕，市场回归正轨，诸多浏览器再度兴起，也加速了对于统一标准的需求。ES的推动下，JS也在前端站稳了脚，形成了现如今HTML（内容），CSS（表现），JS（行为）三家联手的模式。

Reference

JavaScript面向对象编程指南（第2版）
ESMA-262: http://www.ecma-international.org/publications/standards/Ecma-262.htm

圣战：Space vs Tab

发表于 2018-04-07 | 分类于杂谈

怎么说呢，这就开始了

其实一直在想第一篇博客要写成什么样子，设计过很多宏伟的开篇，也想过以一个类似“Hello World”的程序作为开始，但貌似都比较难以付诸于实现，于是结果总会是一拖再拖。

其实择日不如撞日，倒不如就这样开始好啦~

具体使用的情况，google提供了一份调查数据：

额，怎么说呢，经过40万个Repo，10亿份代码文件，14TB代码的调查，得出了结论——用Golang的都是变态么😏

好吧其实现在都用上IDE了，包括我写blog的时候都是一边看code，一边看Markdown的preview写的，也就不那么纠结于tab和space的圣战了，反正使用IDE之前先按照公司标准或者个人偏好设置一下就好。

其实每一个程序员都有着或多或少的强迫症，代码是否work放在一边，一定要好看，颜值神马的最重要了。

对我个人来讲，写code本就是写意，就要写的开心，写得唯美。想想也是在这条不归路上越走越远了 (ノへ￣、)捂脸

好了，就到这里了，盗图发了第一篇，希望能奠定一下基调O(∩_∩)O~~

Reference

最新编程语言排行榜：https://hellogithub.com/tiobe/
Uku Pattak 10份代码分析报告：http://blog.jobbole.com/105381/

有一辆列车在你面前，列车员问你，“小伙子，你要上车吗？”你就问，“这车去哪，下一站什么时候到，车上还有座位吗？”火车早就开走了，你只能等下一辆。可是下一辆来了你还是面临同样的问题。等了很久，别人已经到西伯利亚了，你还在车站上。
管他呢，上去呀。火车是朝前开的，去哪儿并不重要，关键在于窗外的风景。等你下了火车，你就会感谢我的，因为就算有辆飞机停在旁边你也会二话不说的冲上去的，因为你嫌火车太慢了……

Hello Hexo

发表于 2017-12-31 | 分类于从零开始

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.

Quick Start

Create a new post

1	$ hexo new "My New Post"

More info: Writing

Run server

1	$ hexo server

More info: Server

Generate static files

1	$ hexo generate

More info: Generating

Deploy to remote sites

1	$ hexo deploy

Local preview in one command

1	hexo clean & hexo g & hexo s

More info: Deployment

Shadowin Dark

这不是一个技术博客
这不是一个技术博客
这真的不是一个技术博客

GitHub