联想到了吗，对 HTTP 是否应该使用状态码来表达业务状态的争议，其实颇像「使用异常还是错误码」这个同样老生常谈的问题。有些人大小事都要抛异常；另一些人尝试 catch 一切异常，并永远使用错误码。而当代码要接入一个现有模块时，事情变得更复杂了。

HTTP 通用的错误码（ 4xx, 5xx ）很有限，就像系统定义的异常类型，必然无法涵盖所有错误的情况。但我们不必做二极管，始终在上面提到的两种人间反复横跳：尽管很多错误码是和 HTTP 协议强相关的（比如 411 ），至少常用的 401/403/404 语义可以完美对应项目中一定会出现的几种错误情况；除此之外，简单用 400 表达请求有问题，500 表达服务端有问题，搭配自定义的错误代码即可。

另一个和是否使用 HTTP 错误状态码相似的争议，是「是否要以 REST 方式组织 API 」。是的，生搬硬套的 CRUD 语义没办法定义现实中的所有复杂情况，但也不该因此就彻底抛弃这套被广泛接受的代码组织思路：GET 不应有副作用，PUT 相比 POST 有幂等性；实在不行把一些操作都抽象成某个 Action ，然后所有有副作用的操作一律 POST 也比一团乱麻来得整洁。

https://gist.github.com/ecnelises/c16af59384772e4548ac4e59e13b810f

稍微改了一个，不完美，可以加到自定义 CSS 里

也推荐一下我的 newsletter😁 https://weekly.love
上次在别人那里听到一个说法：给自己固定的时间写，时间结束就发稿，写多少是多少，这样能够缓解压力。

我猜不行，因为系统 API 甚至底层中断里就是把功能键和其他键的位分开的

我记得我上大学那会（ 2014 年）自己就突发奇想要买一台 Mac ，还悄悄找同学借了几千块。那会的 MacBook Pro 从做工、续航、性能等各个方面看都是顶尖，甚至买一台装 Windows 也不算脑抽的选择；并且当年的 OS X （还不叫 macOS ）远比今天稳定，用起来真的很舒服。

因为有些老师自己也用的 MacBook ，所以课程上一开始倒没有很多为难苹果用户的地方，不过听说隔壁专业编程课要用到 Windows 专有 API 。入学的时候没有很多人用 Mac ，到大二大三能慢慢发现很多同学开始又整了 Mac 当主力电脑，把原来的 Windows 做备用。其实 Intel Mac 好歹还能装个虚拟机，所以问题不大，M1 就相对麻烦。

总的来说还是推荐第一台电脑选个中规中矩的 Windows 就行，也不要拉得太满，毕竟等你了解更多以后可能想换电脑，而且现在性价比选择比以前还是更多了。毕竟这个专业实习赚钱也不算难，以后想玩 Mac 了再买一台也不迟（

https://github.com/ecnelises/awesome-wheels

之前有很多零零散散的想法，新开了个坑慢慢填，准备把收集的各种可以做的 Side Project 都拿来

小学时候某个乡土课本上写重庆的地图像什么，上面的人说像展翅的雄鹰。后来有个小测验有道题，问重庆地图像什么，我第一反应是之前看地图册留下的印象，像「人」字。结果老师说不对，应该像雄鹰。争执了好久，最后还是妥协了，不过自此以后深刻意识到有些权威就是傻 X

另外一个离谱的：小学卷子上问水滴石穿告诉我们什么道理，我写的「要珍惜时间」，因为站在石头的角度，总有被滴穿的那天……结果自然也是一个大叉

1. Control+R 这个不多说了
2. 设置 CDPATH 这个环境变量，当你要 cd 的目的地在当前目录下找不到时，shell 会在 CDPATH 里的目录一个一个找有没有这个子目录，如果有，就跳过去
3. rm 202{1,2,3}的意思是 rm 2021 2022 2023
4. 输入 fc 命令，可以让你在一个编辑器里编辑上一条命令，保存退出即是执行
5. 命令结尾的&和 wait 命令
6. Control+Z 和 fg
7. 有正则基础的话，学会 sed/awk 基本的删除、替换、过滤只需要十分钟，更高级的文本操作可以用 perl/ruby 的-e 模式
8. sort 、find 命令以及 xargs ，懂的都懂
9. macOS 下可以用 pbcopy 和 pbpaste 操作剪贴板
10. 会一点 Shell 脚本，哪怕只是循环，有时候生活都可以轻松很多
11. zsh 里可以用首字母代替目录，比如 cd /U/u/C/A 按 Tab 就可以变成 cd /Users/user/Code/Android
12. !!执行上一条命令的时候也可以玩替换，比如上一条命令是 gcc -S -O -I./，!!:s/S/c/ 就相当于 gcc -c -O -I./
13. 除了 cd ，你还能 pushd 和 popd 来进入栈顶的目录
14. !:n 可以表示上一条命令的第 n 个参数，比如 vim a.txt ，然后 rm !:1 就是 rm a.txt
15. autojump
16. ripgrep 和 fuzzyf

这么多楼好像都只说了一种语言，有些语言甚至都没提到。聊点个人看法。

Python
======
算是很多非职业程序员会学习的编程语言，在脚本语言这行里发迹比较早，所以很多 Linux 发行版都会有它。语法中规中矩，除了缩进表示代码层级这点有争议，语言上其他没有让人很恶心的地方，也没有什么难以割舍。Python 比较常用的领域有 C++项目的构建系统、人工智能、若干系统维护的工作，还有一些 Web 项目会用 Python 做。比较大的优点是容易找到有 Python 的环境以及至少会点 Python 的人。

Java
======
用「永远的神」来形容 Java 是没什么问题的。几十年的生态积累非常庞大，如果用它做项目也几乎不用担心招不到人这个问题。Spring 等框架过于复杂，还有 Java 做的桌面程序性能不佳等毛病，让大家对 Java 印象不太好。不过连 Golang 都可以有泛型，那 Java 自然也是可以现代化的。也算是和 Python 挺像，在各自的领域里中规中矩，如果真的不知道选什么，那选它不会有啥大错。多年来许多人觉得 Java 和 C++是竞争对手，至少在今天事实并非如此，它们的优点几乎不重合。

C♯
======
最早是以 Better Java 的形象出道的，时至今日似乎已经走出一条自己的路。曾经有个笑话，说 C♯为什么没有 Spring 这种框架，答案是因为微软没有春天。还有个笑话是说 Java 程序员都戴眼睛，因为他们 can’t see sharp 。这俩笑话其实反映出 C♯的特点，就是语言特性远比 Java 丰富，写起来更爽，但生态不够好，招人更难。如果单纯为学习目的，C♯很值得了解，毕竟其父是 Anders Hejlsberg ，编译器领域上古大佬。

JavaScript
======
一说是披着 Java 语法皮的 Lisp ，几乎绕不开的语言。早年乏善可陈，除了原型继承和对象模型和其他语言差异较大值得了解。因为赶上好时代，一方面性能在各家军备竞赛下彻底高出其他脚本语言一个档次，另一方面各种语言变种层出不穷试图弥补其语言缺陷。到今天算是强大的现代语言，还自带可能是地球上最丰富的库和工具生态（ Java 人家至少没什么人天天想着拿 AST 搞事）。不是你想不想学的问题，时至今日做开发没法绕过它，而且在几乎所有主流平台上都能找到自带的 JavaScript 运行时。这个圈子的程序员一个比一个能整活，人称码农娱乐圈。

PHP
======
「最好的语言」，最早就是一个能编程的模版引擎，Web 领域干简单的活没人比它更快，LAMP 这个缩写简直是一个时代的回忆。后来 PHP 也加了很多东西，包括模仿 Rails 的 Laravel 以及 Swoole ，不过不妨碍大家还是按照它曾经的定位玩。语言方面可以玩的不算多。

Ruby
======
这个在国内算是大冷门吧，不过是我最喜欢的语言之一。Ruby 和 JavaScript 有点像同父异母从小分家的两兄弟，都被人说是批皮的 Lisp 。Ruby 有 Perl 风格的简洁操作、完整的面向对象和函数式能力。高度的动态性使得它表达能力非常强，参考 Sinatra 这样的微型 Web 框架。到 2021 年，Ruby on Rails 依然是 Web 开发领域的最强生产力，这么多年在这块也积累下了不少生态。此前被诟病的几个缺点（没有 JIT 、没有静态类型检查工具、缺少完善方便的异步 I/O ）从 3.0 开始也在被一个个解决。问题是会的人不多，但非常值得个人学习 /写个人项目。

Perl
======
当年骆驼书没看多少页就弃坑了。在类 UNIX 系统上 Perl 可能比 Python 更常见，处理字符串和正则的语法非常简洁强大，以至于有人说这个语言是 Write-only 的，就是写一次以后自己就看不懂了。如今应该只有一些历史悠久的系统里能看到 Perl 的大量使用（新项目里取而代之的往往是 Python ）。Perl 6 做了很多年，除了那个极其鬼畜的 Logo 外，好像很少听说新消息。如果能接受 Perl 的奇葩语法，学一学也是挺有意思的。

Scala
======
对 Scala 了解不多，不多扯淡了。主要印象就是把函数式编程和面向对象缝得比较好，类型系统比主流这些语言强。还有就是因为跑在 JVM 上，所以也能受益于 Java 生态。作者 Martin Odersky 也是编程语言和编译器大佬。没接触过这类语言的话，学学 Scala 应该能开眼界。

Swift
======
大家都知道 Swift 背后是宇宙市值最高公司苹果。但 Swift 算是成也苹果败也苹果。2014 年 Swift 发布，2015 年开源，基本和 Rust 1.0 同一个时间，也都基于 LLVM ，如今两者在 GitHub 的 star 数也差不多。但就业界前景而言，Swift 和 Rust 看起来越差越远。Swift 的核心团队和 LLVM/Clang 相当重合，所以无论是编译器实现还是语言设计，Swift 都有不少出彩之处（更何况极不尊重兼容性的苹果在 Swift 早期，每年都要对语言进行大量破坏性修改，被人调侃一年一个新语言，直到 Swift 4 语言核心才基本稳定，好处就是很多坑被扔掉了），比如多范式的异常处理，算是众多语言里比较之下相当舒适的。如果说 Golang 是所谓的大道至简；那么 Swift 奉行的就是兼容并包，拥有主流编程语言里最多的关键字，最新版加入了 async/await/actor ，接下来的 6.0 还会加入所有权机制，更远还有和 C++的无缝互操作。Swift 社区一直有更远大的理想，比如进军服务端。但终究还是要为苹果的生态服务。Swift 就像班级里那个门门功课考 80 ，每周还有半天缺课（指兼容 Objective-C ）的学生，自然不如那些一些科目满分，另一些不及格的学生引老师注意。BTW ，Swift 的编译器是 C++写的，在这些编译型语言里，算是少数没有自举的。

Kotlin 和 Groovy 了解不多。从 Compose 这个项目就能看出，Kotlin 也充满野心，除了 JVM ，也能编译到 Native 和 JavaScript. Kotlin 、C♯和 Swift 像是奇特的结拜三兄弟，不怕 Feature 多，就怕糖不够甜，各自肩负着父辈平台的野心。

还有一个楼主没有提到的就是 Rust ，工具链完善，性能足够好，生态也在越来越丰富，很对一部分函数式爱好者的胃口。但没有 C++经历恐怕不好理解复杂的语言规则是要解决什么问题，而且乱七八糟的符号有点多，代码看着快跟 Logo 一样丑…

@FungKao
用的 Wordpress 的 Arke 这个主题，为了夜间模式魔改了下 CSS ，在 https://github.com/ecnelises/arke

亮点是，这么多年了，他还在用 TextMate

借楼也发下我的周刊😁： https://weekly.love/
RSS: https://weekly.love/?feed=atom

@ecnelises

Try again...

https://i.imgur.com/Cm9gIAO.jpeg

曾经的合租女生攒下的垃圾，还是已经整理过的哦。其他厕所什么的太恶心也没有照片留下来。

https://i.imgur.com/a/bPmC9II.jpeg

换成中文...

大小端的最小单位是字节而不是位，而且针对的是内存操作中的单个数据，比如 int 、long 、double 等。所以如果你的数据单位也只有一个字节，就不用操心字节序问题。而多个 int 、long 组成的数组，元素之间的顺序也和字节序无关。

怎么理解呢？假设你有这样一个数组，其中两个 32 位 int，值分别是 0x01234567 和 0x89ABCDEF，在小端序机器上，内存里存的字节是 0x67 0x45 0x23 0x01 0xEF 0xCD 0xAB 0x89 ；而大端序上则是 0x01 0x23 0x45 … 0xCD 0xEF

所以你可以看到，大端序更直观，而两者各有各的好处。如今小端序更流行更像是 x86 造成的习惯原因。https://stackoverflow.com/questions/5185551

你想问的是，数据真正存储到文件里用的是什么字节序。严格来说这个问题本身是不存在的，因为字节序描述的是内存中的顺序。但不妨不准确地理解为大端序，因为从硬盘读取到内存里的都是一段一段的字节流，然后你可以随意「理解」为任意类型来读。

但是我们还是没有理解，为什么会有字节序这种东西存在，如何「理解」内存难道不是程序的自由吗？为什么要机器来规定？不是的。字节本身是没有意义的。两组 4 个字节，当作 float 和当作 int 进行相加，结果的字节是完全不一样的。所以机器需要一种确定的机制来从内存读数据到寄存器，或者直接从两个内存地址读数据进行操作。所以字节序只对机器指令集能够原生支持的数据类型有意义。