Catalina's notarization is a disaster for cli apps. You may like to disable it with the following command:
sudo spctl --master-disable
{ pkgs, sumFile }: | |
with pkgs; | |
let | |
mod2prefix = path: version: hash: | |
let | |
fullpath = "${path}@${lib.strings.removeSuffix "/go.mod" version}"; | |
manifest = runCommand "${fullpath}.manifest" | |
{ | |
outputHashMode = "flat"; | |
outputHashAlgo = "sha256"; |
# Put the line below in /etc/pam.d/sudo, before other lines | |
auth sufficient pam_tid.so |
package main | |
import "time" | |
// https://dave.cheney.net/2014/10/17/functional-options-for-friendly-apis | |
type Client struct { | |
addr string | |
timeout time.Duration | |
} |
package temp | |
import ( | |
"fmt" | |
"github.com/rs/zerolog" | |
"go.uber.org/zap" | |
"go.uber.org/zap/zapcore" | |
"io/ioutil" | |
"testing" |
Catalina's notarization is a disaster for cli apps. You may like to disable it with the following command:
sudo spctl --master-disable
I was at Amazon for about six and a half years, and now I've been at Google for that long. One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.
I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out. And their operations are a mess; they don't real
*://*.cengji.com/* | |
*://*.kknews.cc/* | |
*://read01.com/* | |
*://blog.csdn.net/* | |
*://help.aliyun.com/wordpower/* | |
*://cloud.tencent.com/developer/information/* | |
*://www.liankexing.com/* |
{ | |
/* Override symbols so other apps can bind */ | |
/* ~ stands for option, ^ stands for control */ | |
"~j" = "noop:"; | |
"~i" = "noop:"; | |
"~;" = "noop:"; | |
"~a" = "noop:"; | |
"~2" = "noop:"; | |
"~g" = "noop:"; | |
"~y" = "noop:"; |
采取 RESTful 风格的 api 是否应该对结果包一层?
又是基于 HTTP 的 API 设计问题
我个人的想法是:
RESTful 和 RPC 风格各有优劣,具体场景具体分析,但是整体一致最重要,不一致的 API 始终是最糟糕的。
如果要添加错误码,错误码最好放在 HTTP 头里面,这样可以在不读取 payload 的情况下判断是否存在错误
例如:X-Error-Code: 10001
或者 X-Error-Code: OUT_OF_CREDIT