SHUHARI 的博客

流光飞舞

分类 IT杂谈

放弃了用 Go 重写网站的决定

2020-03-25

我曾经说过,现在也仍然认为————个人网站就是用来折腾的。本站也经过几次重写,主要是想要体验不同的语言和框架在完成一个实际项目的时候有哪些差别。最近一次重写遇到了 Python 在性能方面的某些问题(具体看这里),因此我也开始考虑是否可以用性能比较强的静态语言来重写,以目前各种语言的发展态势来看,Go 似乎是一个比较合理的选择。

说透 CSV 格式

2019-10-19

CSV 这么简单的格式,需要单独一篇文章来说明吗?其实细节隐藏在魔鬼之中,我们过去的团队在生成 CSV 内容的时候,由于兼容性问题也是吃过苦头的。因此,我觉得还是有必要写一篇文章,从各个方面把这个格式彻底讲透。

本文将介绍:

  • CSV 格式的来源、历史背景和规范化情况;
  • 规范化的 CSV 格式要求与实际支持情况;
  • Python 内置库与第三方库处理 CSV 的接口与细节;
  • 处理 CSV 格式应该注意的常见问题和注意事项。

阿里云、GitLab 与客户或许都有责任 - 阿里云代码泄露事件评论

过去几天,关于阿里云代码仓库权限设置问题,导致多个大型企业信息与数据外泄的消息,引起了开发者社区的不少关注与讨论。事情的原委已有很多新闻网站发表,如 InfoQ 新闻: 一个“Internal”牵扯出的代码泄露,阿里云独家回应,这里不再赘述。我想讨论的是该事件的技术细节以及我个人的看法。

Solid Project:重新定义 Web?

2018-10-01
Web

介绍

Solid Logo

Tim Berners-Lee, Web 的奠基人,由于不满互联网日益被少数大公司所垄断的现实,目前致力于开发一个名为 Solid 的新项目,希望能把管理数据和应用的权力重新归还到用户手中。这个消息估计不少人已经听说过了。基于 Web 的开放思想,Solid 项目也一直是在公开与开源的指导原则下进行的,但直到最近,该项目才逐渐从构想转到实现,我们也终于有具体的细节信息可以一探该项目的究竟。

为什么不应该使用 (OLE)自动化

前言

我喜欢在回答问题之前先考虑另一个问题:这个问题合理吗?但提问题的同学未必会这么想。可能他们已经被项目的压力压迫到不想去思考了,只想得到一个简单粗暴的答案。这个过程其实是一件蛮痛苦的事情,因为我自己需要花额外的精力去思考问题的动机和背景,提问者却经常不领情,并且经常导致我们的对话不在一个频道上。

其中一个典型的案例是关于 Office OLE 自动化的(大部分是 Excel)。遇到这样的问题,我一般会直接建议放弃这个方案。至于提问者的反应则五花八门,虽然大多还算客气,但我能听出来背后通常有这样的意思:你不想答就不答管那么多干嘛。碰到这样的情况我通常选择沉默,因为很难用一两句话讲清楚自己的意思。但既然有自己的博客了,那么我还是花点功夫来解释一下我的想法。

为什么我(作为程序员)要避开中文

题目可能有些容易引起误会。作为中国人,我们在日常生活中当然要使用中文,这是没有疑问的。然而,在程序员的世界中,我会在很多情况下尽量远离中文。前几天有朋友问我一个有关 GBK 编码的问题,我不愿意回答,他很不理解。但这是我自己思考以后做出的选择。

我并无意让其他人都接受我的意见。不过还是有必要说明一下我做出这些选择的理由,是否认同就是你的事情了。我相信读者的背景和知识范围会对他的选择有极大的影响。所以,觉得百度是世界上最好的搜索引擎的同学可以 Alt + F4 了,这篇文章不是为你写的。

接下来我会说明,在哪些地方尽量不要使用中文,以及为什么要这样做。

那些我不想回答的坏问题

2017-09-14

我喜欢在网站上浏览各种别人提出的问题。有耐心的回答者提供详尽丰富的内容能让人直接受益;有些问题不见得多么有意义,但看看别人大开的脑洞也挺有趣。

但很无奈的现实是:无论在哪里,没有营养的小白问题都占了大多数。尤其在 知乎 这样的地方,人家邀请你,你装没看见吧,不好意思;耐心回复吧,一遍遍解答入门级的问题对我没有任何益处。

说这些并不是因为我鄙视小白;没有人生来就是大牛的。包括我自己,在某些领域或许可以(有点心虚地)自称专家,但在其它不熟悉的行业我就是小白。不过,小白也有小白的道德。因此,我希望把自己看过的,不喜欢的、不合理的、会冒犯观众和回答者的情况,在这里总结一下;也希望以后再有类似问题时,能够直接把总结的内容丢出去作为答复,免得总是要在无意义的事情上浪费太多时间。

这篇文章可能没有多少深度可言,其实大部分内容别人已经说过很多遍了,主要是写给初级用户听/看的。对于有丰富网上问答经验的读者,建议看到这里就可以直接关掉窗口了。

用雷达图帮你做技术选型

软件开发行业一个经久不衰的主题是:如何从一堆不同的技术(语言、类库、框架、应用、数据库 etc...)中做出选择。这也难怪,因为可以选择的轮子实在太多了。

当这种问题出现的时候,通常看到的局面是——一群不关己事的人七嘴八舌的评论这个好,那个不好,有时候还会有人强行安利和问题本身不大的内容。结果往往并不好。因为提问者会问出这个问题,说明他自己缺少足够的背景知识,再听上这么多东拉西扯的意见,不昏头转向才对。

事实上,做技术选择也可以是有方法、有套路的。我在这里介绍一种有用的思考方法:雷达图。

Beyond What?——十年之后,谈谈 Ruby, Rails,过去和未来 (二)

Beyond Java

上一篇文章 中,我们讲到了 Ruby / Rails 为何没有如先前人们预期的那样成为业界开发的主流——主要是在技术的层面上。但我觉得似乎还缺点什么。

有意思的是,Rails 当初之所以被当作 Java 的继承者,主要原因是在开发效率上有10倍的差距(撇开其中的宣传成分不论)。而之后被众多网站弃用,则是因为在性能上比后继者有10倍以上差距——这个变化当然有点讽刺意味,却也道出了一个事实:开发的风向已经变了。

Beyond What?——十年之后,谈谈 Ruby, Rails,过去和未来

Beyond Java

2005年,Java 开发者和专栏作家 Bruce Tate 写下了 《Beyond Java》 一书(中译本《超越 Java》,2007年出版)。该书的主要目标是探讨 Java 企业开发的发展方向。尽管作者尽力避免对未来做出明确的预言,但通读全书后,含义仍然是非常明显的:以 Ruby 编程语言和 Rails 框架为代表的新一代编程技术将会超越 Java,引导下一个时代的开发潮流。

需要说明的是,该书提出的观点并不只是作者的个人意见,而是在很大程度上代表了当时很多具有前瞻思想的开发者、包括一些著名业界领袖的共识。要理解这一点,首先需要了解 Ruby / Rails 兴起的历史背景。

浏览器是更强大的IDE

虽然我很多时间都在做和 Web 网站相关的开发工作,但很少有机会从另一个角度去看待这件领域。直到有一天,我和设计师沟通需求时,看着他在浏览器里打开开发工具,直接修改线上的网页样式,然后观察效果,这样反复几次,最后效果满意了,再把完成的样式复制到自己的设计稿里。

那一刻我被深深触动了。尽管从技术上说这并不是多么稀奇的事情,甚至我自己也做过好多次类似的事情,但是从旁观者的视角,却让我意识到自己过去一直不太注重的一个事实:浏览器实际上是一个非常强大的IDE,甚至比某些人喜欢挂在嘴边的“宇宙最强”,在某些方面更加强大。

日本:多难兴邦?

2017-06-01

最近阅读知乎书刊《浅谈日本IT行业》,其中一些内容让我颇有感触。

我个人对历史日本IT行业了解非常有限,仅仅知道曾经有一段时间日本IT曾经对整个行业有不少贡献。除了电器游戏什么的就不必提,诸如禅道、Matz 的 Ruby 语言、源自制造业的精益思想,都是我们熟知的内容。但是这本杂志的叙述却让我看到另外一个自成一体、因循守旧的日本。比如,日本互联网从 90 年代开始兴起,和美、中基本上处在同一时间线,然而和中美不同,日本互联网从兴起时就受到国内标准的严重制约,以至于 TCP/IP 这样的基础通信协议在境内都难以推行。讽刺的是,发生在 1995 年的阪神大地震却意外成为互联网推进的契机:在大灾难发生时,日本人才发现通过电子邮件与国际友人和志愿者通信比普通方式更加快捷方便,而互联网在信息传播上也高效得多,这才使得互联网在日本国内得到了长足 的发展。而智能手机通信 App 和 SNS 也是在 2011 年大地震之后迅速普及的。