V2EX › index90 的所有回复 › 第 22 页 / 共 27 页

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

1 ... 14 15 16 17 18 19 20 21 22 23 ... 27

❮

❯

2019-04-08 10:36:00 +08:00

回复了 pytth 创建的主题 › 程序员 › 专科毕业 3 年，目前存款 15 万左右，想买车行吗？

广州……养车太贵，比深圳还贵，最贵的是停车费。
我一年开 1 万 5 千公里，油费路费保养停车保险总共 2~3 万。
贵的不是买车，而是养车

2019-04-07 22:34:27 +08:00

回复了 bwangel 创建的主题 › Go 编程语言 › 一条面试题引发的思考 Go 版本

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

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

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

2019-04-07 22:04:57 +08:00

回复了 bwangel 创建的主题 › Go 编程语言 › 一条面试题引发的思考 Go 版本

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
}
}

2019-04-07 19:31:01 +08:00

回复了 bwangel 创建的主题 › Go 编程语言 › 一条面试题引发的思考 Go 版本

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

2019-04-07 19:28:57 +08:00

回复了 bwangel 创建的主题 › Go 编程语言 › 一条面试题引发的思考 Go 版本

```
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

2019-03-29 15:08:31 +08:00

回复了 Orenoid 创建的主题 › 程序员 › 问个 RESTful API 设计的问题

@superZzr 看 #16

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

2019-03-28 17:32:56 +08:00

回复了 luxiaokuo 创建的主题 › 程序员 › Mac 最好用的 Git 图形客户端还是 SourceTree 吗? Git-fork 怎么样? 还有哪些呢?

感觉都差不多，SourceTree 转到 GitKraken

2019-03-28 11:27:12 +08:00

回复了 Orenoid 创建的主题 › 程序员 › 问个 RESTful API 设计的问题

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

2019-03-28 11:25:19 +08:00

回复了 Orenoid 创建的主题 › 程序员 › 问个 RESTful API 设计的问题

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

2019-03-27 18:38:46 +08:00

回复了 scckk 创建的主题 › 程序员 › 本人大一新生，学校是大类招生，计算机类，网络工程和计算机科学与技术那个比较好？？

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

2019-03-27 18:03:09 +08:00

回复了 index90 创建的主题 › Go 编程语言 › 锁实现与 Channel 实现的区别？

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

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

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

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

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

2019-03-27 13:46:03 +08:00

回复了 hellowes 创建的主题 › 新手求助 › Windows 真的不适合开发吗？

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

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

2019-03-27 13:30:00 +08:00

回复了 hellowes 创建的主题 › 新手求助 › Windows 真的不适合开发吗？

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

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

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

2019-03-27 10:36:16 +08:00

回复了 hellowes 创建的主题 › 新手求助 › Windows 真的不适合开发吗？

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

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

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

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

2019-03-25 16:36:40 +08:00

回复了 shallyy 创建的主题 › 生活 › 三线城市上车月供 12k 心慌慌

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

2019-03-22 15:05:31 +08:00

回复了 abcyuxue123 创建的主题 › 程序员 › 求推荐一款轻薄的电脑来装 ubuntu

https://www.ubuntu.com/index_kylin

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

2019-03-21 18:24:48 +08:00

回复了 kuoruan 创建的主题 › 程序员 › RESTful 风格的验证码接口应该如何设计？

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

1 ... 14 15 16 17 18 19 20 21 22 23 ... 27

❮

❯