@myself659
编写一个程序，开启 3 个线程 A,B,C，这三个线程的输出分别为 A、B、C，每个线程将自己的 输出在屏幕上打印 10 遍，要求输出的结果必须按顺序显示。如：ABCABCABC....

关键点：
1. 3 个线程
2. 每个线程将自己的输出打印
3. 每个线程都打印 10 遍

所以我说，在 main 中 for 10 次，或者在 main 中打印，都应该算作弊

package main

import "fmt"

func T(msg string) chan struct{} {
ch := make(chan struct{})
go func() {
defer close(ch)
for i:=0;i<10;i++ {
<-ch
fmt.Println(msg)
ch<- struct{}{}
}
}()
return ch
}

func main() {
A := T("A")
B := T("B")
C := T("C")
t := struct{}{}
for ; ; {
A <- t
B <- <- A
C <- <- B
t = <- C
}
}

补充一下，在主线程打印有点作弊，如果在子线程中打印，应该才是题目本意？

```
package main

import "fmt"

type Message struct {
msg string
ch chan bool
}

func T(msg string) chan Message {
w := make(chan bool)
c := make(chan Message)
go func(){
defer close(c)
for i:=0;i<10;i++ {
c <- Message{msg:msg, ch:w}
<-w
}
}()
return c
}

func main() {
A := T("A")
B := T("B")
C := T("C")
for i:=0;i<10;i++ {
a := <-A;fmt.Println(a.msg)
b := <-B;fmt.Println(b.msg)
c := <-C;fmt.Println(c.msg)
a.ch <- true
b.ch <- true
c.ch <- true
}
}
```
出自油管[19:21] ： https://www.youtube.com/watch?v=f6kdp27TYZs

@superZzr 看 #16

面向前端的接口要站在前端的角度去设计，所谓资源，也是前端角度的资源

感觉都差不多，SourceTree 转到 GitKraken

如果你是希望一个 URI 可以显式限定可修改字段，可以这样设计：
PUT /path/to/resource/A,B // 修改 A，B 属性
PUT /path/to/resource/B,C // 修改 B，C 属性

我觉得没有问题啊。
PATCH 更新部分字段，PUT 更新所有字段，如果前端用 PATCH，他传什么属性就修改什么属性啊。问题在哪里？我没读懂

CS 才是本科正统学科，其他都是国情需要搞出来的。

@xrlin 如果其中一个 channel 在处理中，其他 channel 也会被阻塞，这个和 Lock 类似。

不过也可以实现队列：ccb.stateChangeQueue，来避免阻塞。

Unlock 会触发异常，这个会产生什么异常？使用 channel 可读性更强，目前还没习惯，可能思维还没转换过来。

就为实现“顺序调用对象的 function ”这个问题上，我只是觉得用锁实现的话，代码量会少一点。

上面示例之所以非使用 channel 不可，我觉得是因为 ccb.stateChangeQueue 需要非阻塞，所以要用 Channel，不知道我理解是否正确？

说到底，还是舍不得花钱，Macbook 如果只要 5K 一台，估计就没这个帖子了。

分享两句话：
“这是生产工具，值得花钱” ——鲁迅
“钱和时间比，时间更贵” ——鲁迅

@felixcode 我用过 windows，也用过两年 arch，懂得去配置 vim，配置 awesome，对于个人来说当然是最适合，毕竟你的工作桌面是按照你个人喜好来配置的。代价是你要花时间去学，去研究如何配置一个桌面环境。

对于还只是使用默认桌面环境，vim 只是去下载别人配置包的同学，这种优势就消失了。用了两年 arch，花了大量时间在环境配置上，我可能是个强迫症，一直没有配置到满意，正事却没做什么。可能我比较笨，所以我尊称你为大神。

于是我买了 Mac，从此告别配置，开箱即用。省下一些时间，搞搞开发，看看电影，打打游戏，当当现充。

Windows 适合开发，工具完善，开发环境有什么问题，连百度都能找到答案。

无法理解用 Linux 作为开发系统的人是怎么想的，见过一些大神甚至会用 Gentoo，再装个 awesome 简直不能再炫，这类纯粹是热爱吧。大神毕竟是少数，大部分纯粹为了积累多一点 Linux 的操作经验吧，毕竟面试都会问一句，有没有 Linux 的操作经验 balabala。Linux 除非会折腾，否则操作体验几乎为零。

个人在用 OSX，一旦用了 OSX，你会觉得其他都是辣鸡。

总结：Windows 适合做开发，特别适合做微软系列的开发。如果不考虑微软系列的开发，OSX is the best ！

一线月供 8K，三线 12K x 30 年，什么概念

https://www.ubuntu.com/index_kylin

上官方首页，看看首页那台笔记本是什么

RestFul 不是规范，是一种建议，所以没有唯一答案，但有一个共同的目标，就是尽量在不阅读文字解析的情况下，只需要看 method 和 url，就知道你这个接口在做什么。

1. 获取验证码，感觉你的方案有点技术化思维，虽然对于你后台实现来说，是生成一个验证码，但是对于调用方来说，就是获取一个验证码。接口定义应该站在使用方角度去设计，所以应该用 GET /api/v1/{request_id}/captcha。如果你们的接口规范有要求每一个请求都会有 X-Request-ID，可以简化为：GET /api/v1/captcha。

2. 验证的时候，我习惯用 POST：POST /api/v1/{request_id}/captcha/{id} 或 POST /api/v1/captcha/{id}，body 传 value。

这里有个关键问题，RestFul 是为资源的操作而设计的，如果对于“ rpc ”类调用，很难表达“动作”，我是参考 elasticsearch 的 API 设计，他们采用在 URL 末端增加操作字段，例如：POST /api/v1/{request_id}/captcha/{id}/_validate

@bwangel 额，貌似跟你说的不在一条线上，可能我没理解？

楼主提的是，“程序员”看问题的方式，思维和角度都比较单一，几乎就只有“二元”，貌似和是否进取没有关系。

其实，楼主在这里提这个问题，有点“找事”。能 get 到 point 的，实在太少，如果大家都能 get 到的话，楼主也不会在这里提这个问题了。


@TomatoYuyuko 想起以前，看到那些程序员自黑的图或者视频，那时候还是挺引以为豪的，总觉得这是自己职业的可爱点，现在反而有点讨厌，有点被羞辱的感觉了。我现在自我介绍都不说是程序员了，要问就说是工程师，再问就是软件工程师。