随笔-89  评论-944  文章-0  trackbacks-0
  2020年9月20日

这个“伪需求”是最近才想到的。

关于文章管理的想法,说来话长。我最初是在 CSDN 写技术文章,就用网页上的编辑器。后来在 CppBlog 写,用上了 Windows Live Write,一般在 Word 里面写好,再贴到 WLW 发布。再后来由于太忙了,一直停到现在。其中除了我懒,有两个客观原因,第一是中间好几年不搞 C++,那么在 CppBlog 上写非 C++ 的东西好像有点奇怪;第二是,服务端的东西真的没法每天下班自己玩呀,每天下班提心吊胆地看短信报警,也没哪个心情和时间再去重新开辟一个和白天工作内容迥异的学习场景维持下去。(佩服自己找借口的能力~)

前些年,Markdown 兴起,GitHub Pages 兴起,一众静态博客工具也蓬勃发展。Markdown 真的太适合用来写技术博客了,唯一不足是图片的处理。尽管如此,我还是花了很大的精力把以前所有的文章都转成了 Markdown。然后曾经一度也玩上了 GitHub Pages,用 Huge 生成静态博客。然而,博客的这东西我认为价值点和动力还是在于交流、碰撞,自己写自己看,跟存本地没啥区别——我的 GitHub Pages 几乎没人看……那时候也没写几篇,大概是 2018 年末到 2019 年初的时间。

半年前,我想到了近年来第一个“伪需求”。我嫌 Hugo 这种形态操作太罗嗦:先写 Markdown,再放到 source repo 的 post 里,提交一把;再生成静态页面,把 public 提交到 public repo。如果折腾模版啥的,就更复杂。我就想写 Markdown,写完提交一次 .md,能不能就看到呢?甚至干脆不提交,直接同步到服务端。这样,就得做一套动态系统(相对于 Hogo 的静态页面)去做这件事,而生成被浏览的数据的逻辑理论上跟 Hugo 之类的没本质区别。而一般个人博客这种文章量,根本不用纳入性能上的考量,因此做成动态是完全可操作的。看了下市面上没有此类的工具,于是就开搞了。我把它叫“NoteIsSite”,GitHub 地址 https://github.com/Streamlet/NoteIsSite,Demo 地址 https://note-is-site.streamlet.org/,然后把我所有的文章也用这个工具挂在主页下的一个子分类,见 https://www.streamlet.org/note/。关于这个,以后再开一篇文章细说。

到这里为止,写的过程代价很小了。但是刚才说了,博客这东西,对于我的动力很大一部分来自于评论、碰撞,还是需要发到公共平台上去的好。最近看到一个去年离职的前同事的博客 https://gclxry.com/,我惊叹于人家一直在坚持写。我想我是不是也要捡起来了,还是回归 CppBlog 吧。于是问题就来了。最近觉得最好用的 Markdown 编辑器是 typora,然后它没法发博客;以前的 WLW 虽然还能用,但毕竟不基于 Markdown。然而 typora 不开源,没法给他加一个“发布”功能了事。所以自己做做看?顺便入一下 Electron 的坑,以及前端的坑。

花了这么大篇幅把需求来源说完了。至于为什么选 Electron 呢?就是为了快点搞定……

上周学习了下 Electron 的 demo 以及打包流程:https://github.com/StreamletStudy/ElectronHelloWorld

然后正式用这个 repo:https://github.com/Streamlet/MarkdownBlog 现在功能就两个:编辑、发布。编辑不是所见即所得的,左边 Markdown,右边 HTML。发布要每次填 API 地址、账号,没做管理。整个流程通了,于是停下来写了这篇文章,用刚写的工具发布上来。

发现了 Electron 的一个坑,只要在页面里调用了 alert,页面上的焦点就有问题,输入框再也无法输入内容了。目前用 remote.dialog.* 替代。不知道有没有正解?

后面的规划:

  1. 搞清楚前端的语言体系,然后选择用原生 JS 还是它的衍生语言,把工程组织进一步完善
  2. 搞清楚 UI 复杂度,看要不要选择一个虚拟 DOM 方案
  3. 撸功能,账号管理等
  4. 撸功能,做成所见即所得
  5. 撸功能,支持图片粘贴、上传

再后面,先不规划,做完了再看。当前版本 Release:https://github.com/Streamlet/MarkdownBlog/releases/tag/publish_to_metaweblog_api

posted @ 2020-09-20 16:03 溪流 阅读(667) | 评论 (0)编辑 收藏

(原发于 GitHub Pages,2019-01-01 23:22:43)

2019 年,我回来了。

不知不觉中,我入 PHP 的坑已经 3 年有余,入 Go 的坑也大半年了。作为不评论不舒服斯基星人,自然要对 Go 品头论足一番的。

总的一句话,Go 的一些特性确实恰到好处,然而更多的地方却是平庸、繁琐、束缚,以至于我想不到它是适合哪些场景的。

静态语言里,C、C++ 有着明显的适用领域:你要想老老实实写程序,不玩任何花招,就用 C 吧,至少你能掌控一切,实在想玩你还有宏这个大杀器;你要想玩点花招,那就用 C++,代价就是需要自身水平更高,能掌控到多大层次就写多大层次,不懂的不要不懂装懂去用,总体来说还是安全的。

脚本语言里,如果要随便写点什么工具,python 啥的挺方便的;写点网络的,就用世界上最好的语言 PHP 吧。什么?你说 Java?实在没办法,体量太大,公司要你用你就用吧。不过就其本质而言,其实 Java 和今天的主角——Go 是同一类的。不是说他们语法像,是指应用场景(不过这个领域拿 PHP 写显然会更爽)。

嗯——为了表达出真实的意思,我想用词稍微犀利点,请先做一下心理建设。

我不怎么懂 Java,就我浅薄的了解而言,如果你的公司、团队有很多傻逼,甚至你自己也是,业务上又正好可以用 Java 界的一些现成的框架、组件,那么用 Java 肯定是没错的啦。它确实有一种魔力,让你无论多傻逼,也绝对写不出错得多么隐蔽、精妙无比的代码;同时让你无论多牛逼,也写不出多么精彩绝伦、言简意赅的代码。Go 也有这种特质,甚至有些地方比起 Java 更有过之而不及。不信请看:

别人家的写法:

r = f(p1, p2 != null ? p2 : p3)
$r = f($p1, $p2 ?? $p3) 

Go 家的写法:

var r someType
if p2 != nil {
	r = f(p1, p2)
} else {
	r = f(p1, p3)
}

为什么要设计成这样?Go 爸爸说:你们有些人啊,会嵌套很多层 ?:,导致代码可读性太差啦,于是禁止你们使用 ?:,这是家法。在这里,作为熊孩子的代表,我来告诉大家怎样写出让 Go 爸爸无语的代码:

	foo := 1
	bar := 2
	var foobar int
	if foo > bar { if bar > 1 { foobar = 1 } else if bar < 0 { foobar = 2 } else { foobar = 3 } } else { if foo >= 3 { foobar = 4 } else { foobar = 5 } }

怎么样?可读性差不差?

看到了吧,这种傻逼是防不住的,他愿意把 ?: 嵌套好多层,它同样可能会把 if else 嵌套好多层。有素质的人会怎么做?遇到 ?: 嵌套太多立马拆成 if else。所以结论是,即使去掉 ?:,傻逼还是傻逼,但是正常的人写代码就会很啰嗦;支持 ?:,傻逼还是傻逼,正常人用起来爽。要知道一层 ?: 的场景占所有 ?: 场景的比例还是很高的吧。我觉得可以这样,Go 爸爸可以统计一些工业级代码库的 ?: 嵌套层数,作为数据支撑(比如自家 Chrome 里一层 ?: 占 95%,两层占 4.9),然后再在语言层面只支持一层 ?:,编译参数可选打开两层,不支持两层以上。这就功在千秋了。

除了 不支持 ?:,Go 爸爸还有很多这样的设计,随便举几个例子:

  1. 不支持默认参数
  2. 不支持运算符重载
  3. 不提供 goroutine id(以及 gls、可重入锁)

特别是第三点,也是这种思路,因为你们可能会滥用,所以我不提供。类似这种“爸爸思路”,是我今天要喷的最大喷点。前两点也许是抄 Java 的,不怪 Go 爸爸。

综上,Go 爸爸通过扼杀一些基本语法或者一些基础信息,来防止傻逼干坏事,同时让正常人用起来很啰嗦,同时还可能防止不了傻逼干坏事。这跟 Java 通过不提供高级语法来防止傻逼干坏事是师出同门啊,而且他们正好都能写网络服务程序,你说它们像不像?

然而,Go 爸爸也有精分的时候,它居然发明语法糖了耶!比如 if 可以执行一个句句。单就这个语法而言,我的态度是中立偏赞。赞是赞 Go 爸爸确实用过心了,某些时候挺方便,还能缩小变量作用域;不过这个总归是可有可无的,毕竟换一行写也不会死,要变量作用域加个大括号就行。

小语法方面倒是有个亮点,那就是 switch 的隐式 break、显式 fallthrough 处理。不多展开了。

除了防傻逼,Go 爸爸还有一个思路,就是只许州官放火,不许百姓点灯。有两个语法点——

  1. 泛型
  2. 逗号ok断言

先说泛型吧。不支持泛型其实我挺能理解的,因为他确实比 ?: 复杂多了,傻逼用不起,?: 都没有,怎么可能会有泛型呢。然而 Go 爸爸有特权呀,它的 map、chan 可都是泛型的哦。但是你要写一个泛型的语法结构的话,对不起没有。

再说逗号ok断言,同样 Go 爸爸要得起,我们要不起。其实我更想要一个这样的语法:当返回值是 xxx, ok 或者 xxx, err 的时候,我如果用一个返回值接,那么就返回第一个,以便链式调用,同时 !ok 或者 err != nil 的时候 panic。

以上两小点虽然是在喷,不过还好啦。无所谓的。下面讲几个大的方面。

代码组织

我特别赞赏 Go 对于 package 级严格的循环依赖检查。然而如果加上其他规则:

  • 一个目录一个 package
  • 不同路径下的同名目录也是不同 package
  • go 代码无法拆成 .h、.cpp

实际可操作性就会非常差。要拆 package,就要把依赖关系梳理得特别严格,半点不得马虎。这对工一般的程代码来说是个极大的挑战。

我更倾向于做成函数级循环依赖检查,或者不限制(毕竟递归函数也是要支持的嘛)。

这部分,中立偏喷,偏喷是因为 Go 爸爸用了我的小名 internal。

OOP

我特别赞赏 Go 对于 OOP 泛滥成灾的思考与探索,以及对于终结这阵 Java 带来的不正之风的决心。怎么可能万物都是 class 呢。但同时,Go 还是有点矫枉过正的,如果我需要利用传统的 OOP 来搞事情,就非常麻烦,你甚至都无法写出一个框架来。你只能写库让别人用。虽然我也不喜欢框架,但有的时候是需要框架的。

defer 非常切中痛点,特别解决一堆错误 return 外加资源释放的问题。相比之下C 里只能用 goto,C++ 本身不支持但可以玩出 LOKI_ON_BLOCK_EXIT 或者 BOOST_SCOPE_EXIT。defer 一举解决问题。(要是能再增加命名 defer 以及撤销 defer 的功能就更好了。没错,你也许看出来了,我觉得 LOKI_ON_BLOCK_EXIT 是最完美的方案。)

虽然 defer 很好,但不意味着析构就没用武之地了。理想的情况是,析构、多态、defer 都要有……

这部分我的态度是中立。

错误处理

终于要点赞了。错误处理是在我看来 go 完胜的地方,恰到好处地处理问题,又防止滥用。也矫正 Java 带来的歪风邪气。

Java 的设计,让人不得不用异常来处理业务。甚至 Java 自己还帮我们分好类了:一种是不是异常的异常,用来处理业务;另一种是真的异常。一些用惯 Java 的傻逼跑到 C++、PHP、Python 里乱拉屎,到处是 try catch。

Go 爸爸一声令下,万籁俱寂。

goroutine

最后不得不说说 gorouthine,毕竟是卖点嘛。我的态度中立偏赞。赞是因为这是一种太有创意的方案,居然想在在语言层面解决多线程、并发问题;不过我还是觉得这更多的是应用层面的问题,做到官方库里会更好,而不是做成语法。

总结

刚开始用 Go 的时候,特别亮眼,简直处处是亮点,然后越接触越讨厌,一点也不耐看……看得出来,设计者糅合了 C、python、Java 的一些特性,并融入了自己的独特的理解。Go的设计者真的特别特立独行且坚持己见,一些我喜欢的特性因为他们的坚持而存在下来,一些我讨厌的特性也因为他们的坚(Gu)持(Zhi)而不能有所改观。就这样的 Go,想代替 C 作为系统语言,是没戏的;想在网络服务有一番作为,抢 Java 的份额,或许是有机会的,不过最多只能抢 Java 的,连 C# 的都抢不了,C++、PHP 更抢不了。

嗯,除了特定的不得不用的场合,反正我是不会特意用 Go 的。

2019,新年快乐!

posted @ 2020-09-20 14:16 溪流 阅读(656) | 评论 (0)编辑 收藏

(原发于 GitHub Pages,2018-10-13 13:51:09)

两年前我从一名光荣的C++程序员专业为PHP程序员以后,告别了世界第一IDE Visual Studio,改用当时觉得特别难用的 PHPStorm。用了这么久以后,觉得IntelliJ系列虽比不上VS,大概也有世界第二吧,至少比eclipse强太多。除了慢大概也没啥好吐槽的了。

最近又要写Go又要写PHP,最开始PHPStorm和GoLand一起用,后来想,用两个渠道包干嘛呢,还使用他们家的主打产品Idea吧。。。

虽然说程序员一般是要用英文版的,不管是为了实用还是为了装逼。但为了更多人能入门,我们发起一个开源项目来汉化吧,在 https://github.com/Streamlet/ideaLocalization,欢迎有志之士加入。

我们主要就是翻译 resources.jar。代码框架是这样的,resources\en 是原文件解压后的,resources\zh-CN是复制了一份resources\en,我们只要在resources\zh-CN里面就地改动即可。

build.py会把散着的文件们打包成resources.jar。jar里的properties文件里,如果有中文,不能直接是UTF或GBK,必须转成\uXXXX的写法。这个build.py会帮忙转,因此resources\zh-CN里直接写中文(UTF-8)就好。

就是发起个项目意思意思,估计我是没时间翻译的……^_^


当前进度

已完成:

  • 主界面菜单栏翻译

使用方法

  1. 获取语言包。您可以:
    • 直接从 release 列表下载 resource_zh_CN.jar
    • clone 本项目,运行本项目根目录的 build.py 来生成 resource_zh_CN.jar
  2. 将语言包复制到 idea 安装目录的 lib 目录下,复制到 lib 目录下,复制到 lib 目录下
  3. 重启 idea

注意事项

  • 取决于不同操作系统,您可能需要将系统的界面语言设置为简体中文(zh-CN)才能生效。
  • 本项目目前只针对 idea,对于 jetBrains 的其他产品尚未做适配,理论上可能支持或部分支持,请自行尝试。

加入我们

本项目诚邀您的加入,欢迎您贡献自己的力量。

  • 您只需原地修改 resources 下的文件即可,可以在空闲的时候修改一个文件、甚至一行
  • 本项目谢绝直接的自动翻译,但不介意您个人使用自动翻译进行某种形式的协助,但最终请您进行人工核对
  • 本项目遵循软件行业通用的翻译规范,同时对标 Visual Studio 的翻译。请自行体会。下面会罗列一些细则。

分支说明

  • dev_build_script: 专门修改构建脚本
  • dev_readme:专门修改 readme
  • original_resources_tracker: 英文资源文件
  • dev_translate:翻译

合并策略

  • dev_build_script 每次修改并测试通过后合入 master
  • dev_readme 每次修改稳定后合入 master
  • original_resources_tracker 每次更新资源后打 tag,合入 master
  • dev_translate 经常性地从 master 合并新的提交
    • 当 dev_translate 稳定后,从 dev_translate 进行发布
    • dev_translate 在发布时必须处于对 master 可 Fast-Forward 状态
    • dev_translate 发布之后 master Fast-Forward 到 dev_translate

协作方式

  • Fork 版本库,在 dev_translate 上修改,提交 pull request 回来
  • 未来时机成熟的话,成立一个 github 上的 oraganization,届时加入

翻译规范

  • 标点:行文中一般使用中文半角,某些形式文案中可能需要用英文半角符号
    • 需要打开对话框操作的菜单项,使用英文半角的三个点(“...”)表示
    • 菜单项/按钮后的快捷键两侧使用英文半角括号
  • 中英文混排:中文和英文之间需要使用一个半角空格进行分隔
  • 菜单项/按钮的快捷键:放在文案之后,如“文件(<u>F</u>)”

词汇表

英文 推荐翻译 不推荐的翻译
View 视图 查看
Build 生成 构建
posted @ 2020-09-20 14:00 溪流 阅读(612) | 评论 (1)编辑 收藏

4月份就有人留言旧微软拼音恢复工具不支持Win10 1803了,我自己也遇到了,但因为没时间搞,勉为其难使用了词组模式的微软拼音几个月,终于在八月份抽个空研究了下,解决了。

这次是因为傻逼大微软改了 System32\IME\shared 里的东西,导致旧系统拷过来的文件与 System32\IME\shared 的东西不兼容了。解决方式很暴力:从以前的版本复制 System32\IME\shared 过来。

下载:https://www.streamlet.org/software/mspyforever/

(原发于 GitHub Pages,2018-10-13 13:36:04)

posted @ 2020-09-20 13:53 溪流 阅读(18) | 评论 (0)编辑 收藏

近日又一次忍不了Win10的傻逼了,把主要设备降级回 Win8.1 了,配合 StartIsBack 以及 AeroGlass 使用。之所以没降级回 Win7,是因为当年买的大 Surface,只能 UEFI 启动。于是所有系统都 Win8.1 吧。当然 Metro 是不使用的。

就看傻逼大微软什么时候才能从 Metro、UWP 回头,不然我只能当微软一辈子黑了。

然后没想到过程中还有惊喜!我习惯把 OneDrive 目录放到 D 盘,这样每次换系统就不用重新下载文件了。这回换到 Win8.1 后,发现 D:\OneDrive 无法访问了,且不是 NTFS 权限的问题,且无法改权限。估计在文件系统里搞了什么手脚。搞了好久搞不定,只能升级到 Win10,再复制一个备份,再删掉。

特此提醒广大人民群众注意。

(原发于 GutHub Pages,2018-10-13 13:43:05)

posted @ 2020-09-20 13:47 溪流 阅读(25) | 评论 (0)编辑 收藏
仅列出标题  下一页