呓|Jarlyyn's website

工地 > 用golang重做了blog

2017-02-21

在熟悉golang的时候，练手做了一套middleware

链接:herb-go

顺手把网站重做了一下，作为测试。

总体来说，golang的模板系统在熟悉后还是很棒的，很容易就把php模板转了过来。一开始准备用mustache做模板倒显得有些无聊了

数据库这块没用orm,用sql模块还是有些手累新累的

序列化比较蛋疼，gob的序列化不能包裹在函数里，只能传writer,让人无语。相对而言JSON的序列化就好用很多了。可惜我要做页面的缓存，直接缓存[]byte,不适合JSON

http模块的responsewriter的包装也有点麻烦

但看Header里2xxxxx ns的执行时间，还是很爽的

尽管基本都用freecache缓存在内存了

下一步要把后台做出来。现在这样直接更新数据库太恶搞了些

代码 > sqlitebrowser，很不错的sqllit数据库编辑器

2017-01-21

用golang做微博机器人爬语料，玩了下linux编译windows程序，找了这个工具来处理sqlite数据库。

开源，免费，有中文，跨平台

简单操作，易学易用

总的说很不错

http://sqlitebrowser.org/

代码 > golang初印象

2017-01-16

作为一个从Mud机器人正儿八经开始写程序的人，不管是nodejs还是golang,地一个练手项目都选择了mud客户端。

用了下golang,不惊艳，很舒服。

基本上。golang给我的感觉就是一个静态语言版的脚本，或者直接点说，python.

用:=，不需要事先申明变量类型

用interface，实现了脚本语言最重要的ducklike

几块的编译速度，go run xxx.go有种在跑脚本语言的感觉。

强制格式到自动格式化代码。比python更进一步。

很少的关键字。

很适合脚本程序与兼学。

学习成本太低。

虽然还是有很多问题。

但这么多语言，重要的是能做什么，而不是不能做什么。不适合的场景，不用就行了。

代码 > 2017年初，整理下自己的技能树，要有所取舍

2017-01-15

按写过的代码量统计。

1.php，吃饭的家伙，除非改变自己的工作中心，不然不可能绕过去。保持并深入。

2js,同php.区别在于nodejs。就nodejs本身来说，不够喜欢，但胜在和浏览器同源，投入成本极低。保持并深入。

3.lua.可以说，从这个语言开始，是我玩票记录的开始。这个也是我玩票记录的典型。接触熟悉lua是因为当年写的hellua机器人。作为我一个不甚喜欢的语言,突然发现，我的代码量是我不喜欢的语言的排行榜啊。前两个是脏，但实用。lua是简陋。但轻巧。放弃中。

4.python。玩过票，做过gui,折腾过网页程序，写过运维程序。作为一个运维语言，还是少不掉。保持。

5.C。当年做一个别人的毕业设计。和hellua的mapper。以我的功底，能力，行业，没什么前途的。了解过，不擅长，放弃吧。

6.c#。折腾过mono+gtk,读过别人的源代码。放弃吧，能读懂就好。

7.shell脚本。这个也就那样。保持。

8.vb,vbs,logo。入门的东西，忘记就行了。

没怎么接触过，基本之看过一些代码或者做过helloword的语言

9.golang.写过一个helloword。感觉还是有一些有意思的点。深入。

10.c++好像接触过一点，好像又没接触过。不是这块料，放弃吧……

11.Java。太庞大。无力挑战。一直以来没什么好的映像，怎的要选，估计选c#的概率更高。放弃。

12.perl与我哲学不符。放弃

13.ruby。不喜欢rails....放弃。

总结：

深入3个语言 php,js,golang

保持python,shell。

真的有需要，可以考虑学习下c#/java

果然还是菜鸟技能树啊。

代码 > 不错的小玩意--我眼中的golang

2017-01-14

之前被v2ex上一篇热贴吸引，去研究了一下golang。

本身误以为golang是个值得花精力去学好的东西。可以写客户端，效率高，文件直接在一个包内，跨平台。

在部署好环境，写了helloworld后，又对自己想要的方向搜索了下。

结果发现，我虽然长得不美，但想得太美了。

golang完全不是这么回事。

做gui比nodejs还惨。效率和java打了几个来回还输了。都蛋疼到让我去搜索golang的意义了。

好在在洗澡时理清了思路。发现我从一开始纠错了。

Golang压根就不是一个什么通用开发语言，被设计出来本身就是用来做一个小工具。

它的作用只有两个

1.做服务。连网页或者爬虫都做不好，那是动态语言的优势。

2.做运维工具。

颇有静态语言版shell的概念。

他解决问题是

1.作为服务，而非运算能力的效率问题

2.方便部署。各种脚本语言，特别是自带包管理那一票，特别特别是某些2.x 3.x都不兼容语言，在各种环境(比如包管理以来特定版本某语言的centos,比如windows)。部署起来太麻烦了。这点上go太方便了。

3.标准化问题，基本就是个更严格，甚至连文件夹怎么放都限制了的某语言。

既然只是一个做服务/运维的小工具，所以突出易学就很正常了。

难怪看到的资料，大部分都是替换了某语言，他跟就是对着某语言的7寸打的啊。

这对于只掌握一门语言来谋生的 “程序员“来说，应该是痛苦而难以接受的吧……

杂言碎语 > 2016总结

2016-12-30

2016最后一个工作日了。总结一下自己的2016. 总的来说，只有一句话。

过于安逸。

和充满变化的2015完全不同。2016可以说是一个过于安逸，安逸到让我自己都觉得不安的年份。

这一年。没有学什么新的东西，基本就是把2015的东西做了一个深化。

年底时把几个网站更新了。接触了pixijs,但没有保证执行力的推进下去。

公司的话可以说是进入转型期，工作的中心也开始逐渐偏移，从技术偏向正特的管理和运营。

收入增长，有限。

今年唯一在数字上有比较大的变化，大概就是steam上的游戏数量了。

除了女儿的成长，今年某种角度来说可以说是一事无成。

是需要好好反思一下了。

工地 > 2016最后一次网站更新

2016-12-27

修正裸域名https错误。不知道为什么百度收录的都是https://jarln.net的网站。

自适应加入简单的手机版本。

Linux > nginx反代只支持压缩格式的网站

2016-12-22

昨天有个需求，反代客户的一个网站，从域名a,到域名B, 并做本地缓存。

改着改着一脸懵逼。

因为最后发现源网站不能用非压缩的格式访问。

最后通过自己反代自己反代自己的方式解决了。

就是用gnuzip解压，然后再sub_filter替换。

代码为

proxy_cache_path /cache/CACHENAME levels=1:2 keys_zone=CACHEZONE:300m inactive=30d;
proxy_temp_path /cache/tmp;

server {
listen 127.0.0.1:8080 default_server;
server_name _;
gzip on;
location / {
sub_filter 'ORIGINNAME' 'TARGETNAME';
sub_filter_once off;
proxy_pass http://127.0.0.1:8081;
proxy_set_header Host TARGETNAME;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Accept-Encoding "";
}
}
server{
listen 127.0.0.1:8081 default_server;
server_name _;
location / {
proxy_pass http://166.70.53.125;
proxy_set_header ORIGINNAME;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Accept-Encoding gzip;
gunzip on;
}
}
server {
listen 80;
server_name ORIGINNAME;
gzip on;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_connect_timeout 15m;
proxy_ignore_headers Cache-Control Set-Cookie Expires;
proxy_set_header Accept-Encoding gzip;
proxy_set_header Host ORIGINNAME;
proxy_cache CACHEZONE;
proxy_cache_valid 200 302 30d;
proxy_cache_valid 404 1m;
}
}