Seven Qualities of a Great CTO English to Chinese

原文地址,需要科学上网,意译为主,不逐字翻译:

https://medium.com/@peyton.reaves/seven-qualities-of-a-great-cto-b047fd37d30a

好的CTO应该具有的七个品质

I、商业嗅觉

最重要的是,CTO首先是CO,也就是Chief Officer,“首席XX官”。CTO是商业领袖和战略大师,只是更专注于技术领域。好的CTO要对整个业务有深刻理解,才能够做出决策,让技术更好的为业务服务。

II、持续跟踪新科技和新业务

CTO最重要的职责是预测业务将会怎样发展,以及技术怎样满足未来的业务发展需求。持续跟踪和评估高速发展的最新技术,对于保持公司的竞争力、效率和扩张能力极端重要。注意,这并不仅仅是关注最新的操作系统,硬件或者编程语言,还要包括已经被充分验证的开发方法论、测试流程以及将来可以和你的业务与时俱进的平台架构。

III、搞定客户

CTO也应该发挥对外的作用,尤其是与客户打交道的时候。在于现在或潜在客户打交道的时候,CTO的软实力(soft skill)非常重要。CTO需要有亲和力,有同理心,理解市场和行业需求,或许更重要的是,要把复杂的业务术语用客户可以理解的方式讲解出来。注意,当与客户打交道的时候,很可能会有大量的不懂技术的人参与讨论。

IV、丰富的技术背景

CTO应该具有深厚的技术背景。这对于理解不同的技术极有帮助。如果没有技术积累,在整合各项技术的时候,可能会犯错。

V、专注于公司文化

CTO的一个关键专注点应该是为公司的技术部门构建一个良好的文化。作为高管的一员,CTO有机会也有责任为公司构建一个良好的公司文化,包括热爱创新、团队协作精神以及职业荣誉感。专注于技术的文化,结合公司的战略计划,能够有效确保整个公司的持续成功,并吸引到足够且合适的人才加入你们的共同事业。

VI、热心于团建建设和指导

热心于团队建设和指导对于构建一个好的公司文化直接相关。作为CTO,有必要也会机会向同事们分享你的经验和对业务的理解。帮助和辅导其他同事,对构建一个强力团队极端重要,而且也容易发现团队中存在的问题,不至于疏忽某些错误。

VII、Evangelistic 布道精神

前面提到,CTO应该被视为公司技术实力的招牌,这不仅是在客户会谈的时候才有这个作用。还要让客户意识到是公司的品牌和产品支持了客户们的成功。一个对外活跃的CTO会成为业界的思想领袖,对于增加公司和产品的口碑和信誉度有重大助益。

一个有布道精神的CTO会充分利用各种渠道来宣传自己的公司、产品和技术成果,包括但不限于发言、会议、小组讨论、采访和发表文章等。

客官:
如果您喜欢这篇翻译,请打赏,我喝杯咖啡吧。鼓励我继续翻译更多作品!

声明:纯手翻,非机翻。

DSAA Experience 4: Grokking Algorithms

有人曾经曰过:
占有一本书,比占有一本书里的知识容易多了。

其实早就有了这本书《Grokking Algorithms: An illustrated guide for programmers and other curious people》,但我都忘了它了。

直到有一天,需要学习更多的算法了,搜索了一番,挑了一本评价不错的,就这本,但没想到早已经躺在我的百度云盘里两年了。

总体上,这本书非常靠谱,比如讲QuickSort,也就是快排,先讲了Divide & Conquer,然后讲递归(Recursion),然后再用递归来讲解QuickSort,那简直就一下子就明白了。而以前看了好几次Youtube视频,都是理解不能。

总之呢,推荐这本书!

Grokking Algorithms: An illustrated guide for programmers and other curious people

获取方式:
你可以点击购买
如果你没钱,你也可以“百度一下”

The Types of Coders

The Types of Coders

Disclaimer:
I am NOT trying to insult anyone. I am just stating a fact.

There are at least two types of coders, and maybe a third one:

  • too lazy to read the f–king manual
  • too stupid to understand the documentation
  • the third one, “non-coders”, who cann’t code per se. They just like the “tech stuff” and love the feeling of coming up a big idea and then change the universe and “make the world a better place”. Actually, they just want to be super-rich and coding seems to be the shortcut to get there. And obviously, they are opportunists. They would chase all the hot topics, cloud computing, block chain, artificial intelligence, etc. They would achieve nothing.

Update on 3/30/2018

Sometimes, I am the first type. Sometimes, I am the second type. Sometimes, I am both. But I have never been the third type.

Ten Best Practices for Better RESTful API Enlish to Chinese

原文:

https://medium.com/@mwaysolutions/10-best-practices-for-better-restful-api-cbe81b06f291

如果打不开,可以用这个:

https://blog.mwaysolutions.com/2014/06/05/10-best-practices-for-better-restful-api/

翻译:意译为主,不逐字翻译

The concept of REST is to separate the API structure into logical resources. We should use the HTTP methods GET, DELETE, POST and PUT to operate with the resources.

REST的概念,是把API结构进行了分拆。应该使用HTTP方法,诸如GET, POST, PUT, DELETE等对资源进行操作。

1. Use nouns but no verbs 使用名词,不要用动词

例子:

1
2
3
4

/cars,代表所有car

/cars/711,代表某一个car(比如,编号为711的car)

可以用GET, POST, PUT, DELETE等http方法,对cars这个资源进行增删改查

禁止使用下面的URL:

1
2
3
4

/getCars

/deleteCars

2、GET method and query parameters should not alter the state

GET方法以及附带的查询参数,不应该改变资源的状态

译者注:这很显然,查询只是“读”操作,不可以改变资源的状态。

例子:略

3、 Use plural nouns 使用复数名词

1
2
3
4
5
6
7
/cars instead of /car

/users instead of /user

/products instead of /product

/settings instead of /setting

上面例子要求使用复数来描述所有car、user或product。

译者注:其实我是有点不理解的,而且也不太认同这一条。但编程有一个重要的东西就是“约定”,英文是convention,就是说,大家都默认和通用的一套规则,能够有效减少沟通成本。有时候靠猜就可以写出来不错的代码,而不用非要翻文档。我用Express JS的时候,就靠猜写了不少代码。所以convention很重要。但我写的jobserver.io的API没采用这个约定。

补充一下 下面评论的可能情况,如果某些复数要有变体,比如company,怎么弄?所以还不如就单数了。这也算一种新的convention

4、Use sub-resources for relations 使用子资源来表示资源之间的关系

1
2
3
4
5
6
7
8
9
10
11
//Returns a list of drivers for car 711

//返回711号car的所有driver

GET /cars/711/drivers/

//Returns driver #4 for car 711

//返回711号car的4号driver

GET /cars/711/drivers/4

5、Use HTTP headers for serialization formats

Both, client and server, need to know which format is used for the communication. The format has to be specified in the HTTP-Header.

客户端和服务器都需要知道使用那种格式进行通讯。格式要在HTTP header里指出。

Content-Type defines the request format.

Content-Type定义了请求格式

Accept defines a list of acceptable response formats.

Accept定义了响应的格式。

6、Use HATEOAS 使用HATEOAS

HATEOAS是Hypermedia as the Engine of Application State,超媒体即应用状态引擎。

更多关于HATEOAS的内容,请看:Understanding : HATEOAS

7、Provide filtering, sorting, field selection and paging for collections

为资源的集合提供过滤、排序和分页等功能。(怎么翻译field selection?)

Filtering:

Use a unique query parameter for all fields or a query language for filtering.

1
2
3
4
5
6
7
8
9
//Returns a list of red cars 翻译所有红色car

GET /cars?color=red

//Returns a list of cars with a maximum of 2 seats

//返回最多有2个座位的car(这他妈显然是豪车啊)

GET /cars?seats<=2

Sorting:

Allow ascending and descending sorting over multiple fields.

1
GET /cars?sort=-manufactorer,+model

按照制造商(manufactorer)的倒序和型号(model)的升序排列

Field selection

1
GET /cars?fields=manufacturer,model,id,color

只展示car的几个属性,制造商,型号,id,颜色

Paging 分页

1
GET /cars?offset=10&limit=5

To send the total entries back to the user use the custom HTTP header: X-Total-Count.

如果要返回所有car的数量,使用HTTP header:X-Total-Count

连接到下一页或者前一页的url,也要在HTTP header link里给出(这是给服务端说的)。(对于客户端而言,)最好也是使用HTTP header里给的url,而不是自己来构建URL。

1
2
3
4
5
6
7
8

Link: <https://blog.mwaysolutions.com/sample/api/v1/cars?offset=15&limit=5>; rel="next",

<https://blog.mwaysolutions.com/sample/api/v1/cars?offset=50&limit=3>; rel="last",

<https://blog.mwaysolutions.com/sample/api/v1/cars?offset=0&limit=5>; rel="first",

<https://blog.mwaysolutions.com/sample/api/v1/cars?offset=5&limit=5>; rel="prev",

8. Version your API API版本号

API的版本号,习惯和semver不一样,只用“v1””v2” “v3”这样的形式。但最近我也发现有的API是“v1.2”这样的。所以,更多的还是看开发者习惯吧,没有非要怎样怎样的规定。

还有一个问题:关于版本号到底要加在URL里,还是放在HTTP header里,阮一峰有一个看法, 其他人也有一些其他的看法,我曾经发起了一个讨论,大家可以去看一下别人是怎么回复的:RESTful API 设计,到底加不加 版本号? - V2EX

【什么是semver?Semantic Versioning 2.0.0】

9、Handle Errors with HTTP status codes 使用HTTP status code来处理error

使用404,200之类的。这个简单。

Use error payloads 使用error payloads(这是啥?)

这是原文给的例子:

1
2
3
4
5
6
7
8
9
10
11
{
"errors":
[
{
"userMessage": "Sorry, the requested resource does not exist",
"internalMessage": "No car found in the database",
"code": 34,
"more info": "http://dev.mwaysolutions.com/blog/api/v1/errors/12345"
}
]
}

10. Allow overriding HTTP method

Some proxies support only POST and GET methods. To support a RESTful API with these limitations, the API needs a way to override the HTTP method.

某些代理(proxy)仅支持POST和GET方法,那么就需要override一些HTTP方法。

Use the custom HTTP Header X-HTTP-Method-Override to overrider the POST Method.

使用HTTP header X-HTTP-Method-Override来override POST方法。

Thanks for visiting!

感谢观看!

最初发表于知乎,但感觉知乎现在技术讨论氛围也不太行了。

The Levels of Coders

程序员的境界

Eric曾经在知乎上看过一个人写的程序员的境界,我觉得很好,但原答案早已轶失。今天,Eric就尽量回忆,并加上自己的理解来写一写程序员的境界吧。

第零层:知道最基本的配置,能把各项基础设置搭建起来。

  • 这一层看起来简直是跟没有要求是一样的。但说真的,这一层一点也不容易的。
  • 尤其是对于一个一行代码没写的过人来说,比如我。
  • 我以前分不清IDE和Editor的区别,写下的第一行代码还是用Sublime写的,而且很痛苦,因为没有智能提示,每一个字符都要自己手敲。
  • 然后安装各种配置,比如装Python,能把virtualenv搞明白,对于入门级别的程序员来说算不错的了。
  • 比如装Java,每一个教学视频,第一步就是教你怎么安装JDK,配置Path路径,等等。
  • 也就PHP简单一点,直接下载XAMPP即可。
  • 现在Node.js的环境配置也足够简单了,但其他脚手架的搭建可就痛苦许多了,例如Webpack的配置,最近webpack4发布,出现大量的break change,这一下子又难倒了不少人。

第一层:基础语法,基本API,用某个框架写出来第一句Hello World

  • 如果基本配置配好了,其实这一个倒不是很难。
  • 语法不熟悉,多看即便也就习惯了。
  • 很多东西照葫芦画瓢是可以达到的

第二层:CRUD

  • 能用CRUD做出一个凑合能用的东西,其实很多人停留在这一层
  • 很多常用的库,要比较熟练掌握常用的API

第三层:能发现别人的Bug,或者可以修理一些非常简单的bug

  • 要到这一层,你首先要对基本的用法和常用的库有一个比较多的了解
  • 其实这一层比第二层高明不了太多,但差别在于代码量
  • 达到了第二层, 再多写一些代码,自然就会遇到一些简单的bug
  • 即便不会修理,也知道怎么绕过去,这一点还是要的
  • 最不济,也要会搜索,能找到别人的解决方案

基本上这一层之前的人,通过Google能解决到99.99%的问题,所以善用Google很重要

第四层: 个人可以实现一些轮子的原型

  • 包括但不限于:数据结构,算法,Design Pattern,Framework等等
  • 当然,如果有悟性一点,这一层的人可以迅速进入下一层,就是写的东西有别人愿意用

第五层:开发一些别人愿意去使用的东西

  • 这一层已经不是技术占据全部了
  • 不仅会写代码,还要明确知道市场上缺什么,写什么能解决别人的难点和痛点

第六层:个人眼界所限,看不到更上层次的东西了

  • 第六层往上,应该已经不仅是个人的奋斗,也要考虑历史的行程
  • 因为即便是眼光犀利,看到了一个机会,也不见得能取得什么样的成绩
  • 毕竟绝大多数情况下,写代码是工程,一个工程产品,肯定是可以做出来的,剩下就看成本了
  • 而一个工程产品,能在多大程度上被人接收,还要看你的宣传
  • 也和运气和时机有关系
  • 所以要看历史的行程
© 2018 awesome.js All Rights Reserved.
Theme by hiero