出镜率比较高的Golang项目。

记录用的人较多或者出镜率比较高的Golang项目。

如果我漏了你觉得重要的项目,麻烦帮我指出,我尽快补上,谢谢!

下面列表中的每一个项目都配上了Star增长趋势的图片,可以看出该项目的热度。

特别是与区块链相关的两个项目fabricgo-ethereum,能够明显看出区块链行业的起伏。

整理过程中收获:

1、了解到docker项目已经改名为moby,当前仓库为:https://github.com/moby/moby

2、了解到时间序列数据库,库中每一个数据都有时间属性。

项目列表

Gin

仓库地址:https://github.com/gin-gonic/gin

Gin是用Go语言实现的一款web框架。

它的特点和Martini类似,但是API的性能更好,大概快40倍。如果你对性能要求极高,尝试一下Gin,不会让你失望。

Beego

仓库地址:https://github.com/astaxie/beego

一个使用 Go 的思维来帮助您构建并开发 Go 应用程序的开源框架。

一个快速开发 Go 应用的 HTTP 框架,可以用来快速开发 API、Web 及后端服务等各种应用,是一个 RESTful 的框架,主要设计灵感来源于 tornado、sinatra 和 flask 这三个框架,但是结合了 Go 本身的一些特性(interface、struct 嵌入等)而设计的一个框架。

框架特性:简单化智能化模块化高性能

Caddy:

仓库地址:https://github.com/mholt/caddy

一款可以用于生产的开源服务器,具有速度快,易使用,生产效率高的特点。

当前已经可以在WindowsMacLinuxBSDSolaris, and Android使用。

具有如下特点:

  1. 使用Caddyfile方便配置
  2. Auto HTTPS Caddy 使用 Let’s Encrypt 让你的站点全自动变成全站HTTPS,无需任何配置。当然你想使用自己的证书也行。
  3. HTTP/2 全自动支持HTTP/2协议,无需任何配置。
  4. 主机虚拟化使多个站点工作
  5. 可使用插件扩展
  6. 无需依赖即可运行
  7. 为了保证安全连接,使用了TLS session ticket key rotation

Nsq

仓库地址:https://github.com/nsqio/nsq

实时分发的消息平台,用于极大规模的数据处理,处理量级10亿+。

它提升了分布式和去中心化的拓扑结构,没有单点故障,支持容错和高可用性,并保证消息传递的可靠性。

在操作上,NSQ易于配置和部署(所有参数都在命令行上指定,编译后的二进制文件没有运行时依赖项)。为了获得最大的灵活性,它与数据格式无关(消息可以是JSON、MSGPack、协议缓冲区或其他任何格式)。官方的go和python库是现成的(以及许多其他客户机库),如果您有兴趣构建自己的库,这就是一个协议规范。

Hugo

仓库地址:https://github.com/gohugoio/hugo

一个静态的,可伸缩的网页生成器,宣称世界上最快的建站框架,不过这点和wordpress怎么比呢。

Go语言编写的静态网站生成器,速度快,易用,可配置。

Hugo获取一个包含内容和模板的目录,并将其呈现为完整的HTML网站。

Gogs

仓库地址:https://github.com/gogs/gogs

Gogs是一款极易搭建的自助Git服务。

该项目旨在打造一个以最简便的方式搭建简单、稳定和可扩展的自助Git服务。

使用Go语言开发使得Gogs能够通过独立的二进制分发,并且支持Go语言支持的 所有平台,包括 Linux、macOS、Windows 以及 ARM 平台。

Frp

仓库地址:https://github.com/fatedier/frp

frp是一个可用于内网穿透的高性能的反向代理应用,支持 tcp, udp 协议,为 http 和 https 应用协议提供了额外的能力,且尝试性支持了点对点穿透。

Proxypool

仓库地址:https://github.com/henson/proxypool

采集免费的代理资源为爬虫提供有效的IP代理

设计架构:

Getter:代理获取接口,目前有9个免费代理源,每调用一次就会抓取这些网站最新的100个代理放入Channel,可自行添加额外的代理获取接口;

Channel:临时存放采集来的代理,通过访问稳定的网站去验证代理的有效性,有效则存入数据库;

Schedule:用定时的计划任务去检测数据库中代理IP的可用性,删除不可用的代理。同时也会主动通过Getter去获取最新代理;

Api:代理池的访问接口,提供get接口输出JSON,方便爬虫直接使用。

Lantern

仓库地址:https://github.com/getlantern/lantern

区别于,SS,它是分布式的,点对点的,通过蓝灯,你可以和自由上网的用户共享网络,对方可以自由上网,你也就自由了。

SS-go

仓库地址:https://github.com/SS/SS-go

该项目为SS的Go语言实现,项目名称使用SS替代,你懂吧?

Syncthing

仓库地址:https://github.com/syncthing/syncthing

Syncthing是一个持续不断的文件同步项目,能够在两台或者多台电脑上同步文件,使用了其独有的对等自由块交换协议,速度极快。

主要特点:

确保数据的安全性:保护用户的数据是责无旁贷,该项目采取所有的合理的预防措施来避免用户的文件损坏。

确保数据不被攻击:不循序任何未经授权方的窃听或修改。

易于使用

自动化

能够在大多数通用的电脑上使用

Kubernetes

仓库地址:https://github.com/kubernetes/kubernetes

容器编排工具,实现自动化部署,更新,下线,负载均衡,容错处理等。

三个特点:

优化部署:快速而有预期地部署你的应用, 极速地扩展你的应用,增加项目的实例,能够实现自动布局、自动重启、自动复制、自动伸缩,并实现应用的状态检查自我修复

优化资源利用:跨主机编排容器, 更充分地利用硬件资源来最大化地满足企业应用的需求

声明式配置etcd声明式的容器管理,保证所部署的应用按照我们部署的方式运作.

Etcd

仓库地址:https://github.com/etcd-io/etcd

etcd

分布式可靠的键值存储,尤其是分布式系统中极其重要的数据,其特点:

Simple: API设计合理,面向用户

Secure: 自动的TLS连接,支持客户定制认证

Fast: 写入能力大于1w+每秒

Reliable: 使用Raft恰当的分发

etcd当前频繁的和Kubernetes,locksmith,vulcandDoorman等项目配合使用。

Moby

仓库地址:https://github.com/moby/moby

该项目是在容器化生态中组装容器时使用,以前的大名叫做:docker,这个大家都知道。后来经过一段纠结的时刻,改名字了,原因在这儿

docker

Moby是一个开放式项目,旨在维持模块化和灵活性。

模块化:该项目包括的许多组件,优秀的函数和API共同协作。

可交换:Moby包含足够的组件来构建功能齐全的容器系统,但其模块化架构确保大部分组件可以通过不同的实现进行交换。

可用安全性:Moby提供安全的缺省值,无需特殊配置。

Traefik

仓库地址:https://github.com/containous/traefik

Traefik是一款开源的反向代理与负载均衡工具。它最大的优点是能够与常见的微服务系统直接整合,可以实现自动化动态配置。 目前支持 Docker、Swarm、Mesos/Marathon、 Mesos、Kubernetes、Consul、Etcd、Zookeeper、BoltDB、Rest API 等等后端模型。

Influxdb

仓库地址:https://github.com/influxdata/influxdb

influxdb是目前比较流行的时间序列数据库。

时间序列数据库:数据格式里包含Timestamp字段的数据,几乎所有的数据其实都可以打上一个Timestamp字段。

Influxdb是一个开源的分布式时序、时间和指标数据库,使用go语言编写,无需外部依赖。

三大特性:

时序性(Time Series):与时间相关的函数的灵活使用(诸如最大、最小、求和等);

度量(Metrics):对实时大量数据进行计算;

事件(Event):任意事件的数据我们都可以做操作。

influxdb

Prometheus

仓库地址: https://github.com/prometheus/prometheus

一个开源的服务监控系统和时间序列数据库。

Prometheus提供的是一整套监控体系, 包括数据的采集,数据存储,报警,甚至是绘图(只不过很烂,官方也推荐使用 grafana)。 而InfluxDB只是一个时序数据库。同为时间序列数据库,两者对比:prometheus和influxdb对比

Grafana

仓库地址:https://github.com/grafana/grafana

Grafana是一款开源的,具有丰富功能的度量标准仪表板和图形编辑器,用于显示Graphite,Elasticsearch,OpenTSDB,Prometheus和InfluxDB等数据,定制化高。

Go-ethereum

仓库地址:https://github.com/ethereum/go-ethereum

以太坊协议使用Go语言的官方实现。

Fabric

仓库地址:https://github.com/hyperledger/fabric

区块链超级账本Hyperledger Fabric实现,用于联盟链开发。

Drone

仓库地址:https://github.com/drone/drone

Drone是一种基于容器技术的持续交付系统。

Drone使用简单的YAML配置文件(docker-compose的超集)来定义和执行Docker容器中的Pipelines

Drone与流行的源代码管理系统无缝集成,包括GitHub,GitHub Enterprise,Bitbucket等。

欢迎关注公号:程序员的金融圈

作者:大漠胡萝卜
链接:https://juejin.im/post/5cfa2cfef265da1bcc19333e
来源:掘金
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

Things I Learnt The Hard Way (in 30 Years of Software Development)

I discover a useful posts when searching , just repost it.

https://blog.juliobiason.net/thoughts/things-i-learnt-the-hard-way/

Following the original posts

—————————————————————————————-

This is a cynical, clinical collection of things I learnt in 30 years working with software development.

Again, some things are really cynical, others are long observations on different jobs.

Software Development

Spec first, then code

If you don’t know what you’re trying to solve, you don’t know what to code.

Write something specifying how the application works before writing any code.

“Without requirements or design, programming is the art of adding bugs to an empty text file.” — Louis Srygley

Sometimes, even an “elevator pitch” — up to two paragraphs that describe what the application does — is enough.

The times I stood longer looking at my own code wondering what to do next were when we didn’t have the next step defined. It is a good sign that it’s time to stop and discuss it with your coworkers — or maybe rethink the solution.

Write steps as comments

If you have no idea how to start, describe the flow of the application in high level, pure English/your language first. Then fill the spaces between comments with the code.

Better yet: think of every comment as a function, then write the function that does exactly that.

Gherkin is your friend to understand expectations

Gherkin is a test description format which points “Given that the system is in a certain state, When something happens, then this is expected”. Even if you don’t use any testing tool that reads Gherkin, it will give you a good understanding of what it is expected from the app.

Unit tests are good, integration tests are gooder

On my current job, we do test modules and classes only (for example, we write tests for the view layer only, then tests for the controller layer only, and so on). It gives us some idea if things are going right or not, but they lack a view of how the whole is going on — a thing integration tests, which tests how the system as a whole behaves — do better.

Tests make better APIs

We code in layers: There is the storage layer, which should make our data permanent; there is a processing layer, which should do some transformation on the data stored; there is a view layer, which has information on how the data must be present; and so on.

As I mentioned, integration tests feel better, but testing layers by themselves can give you a better view on how their API looks like. Then you can have a better look on how to call things: Is the API too complex? Do you have to keep to much data around to be able to make a single call?

Make tests that you know how to run on the command line

Not that command lines are important for any projects, but when you know the command to run the tests, you know how to automate the execution of the tests, which you then can use in a continuous integration tool.

Be ready to throw your code away

A lot of people, when they start with TDD, get annoyed when you say that you may have to rewrite a lot of stuff, including whatever your already wrote.

TDD was designed to throw code away: The more you learn about your problem, the more you understand that, whatever you wrote, won’t solve the problem in the long run.

You shouldn’t worry about this. Your code is not a wall: if you have to throw it always, it is not wasted material. Surely it means your time writing code was lost, but you got a better understanding about the problem now.

Good languages come with integrated tests

You can be sure that if a language brings a testing framework — even minimal — in its standard library, the ecosystem around it will have better tests than a language that doesn’t carry a testing framework, no matter how good the external testing frameworks for the language are.

Future thinking is future trashing

When developers try to solve a problem, they sometimes try to find a way that will solve all the problems, including the ones that may appear in the future.

But here is the thing: The problems from the future will never come and you’ll end up either having to maintain a huge behemoth of code that will never be fully used or you’ll end up rewriting the whole thing ’cause there is a shitton of unused stuff.

Solve the problem you have right now. Then solve the next one. And the next one. At one point, you’ll realize there is a pattern emerging from those solutions and then you’ll find your “solve everything”.

Documentation is a love letter to your future self

We all know writing the damn docs for functions and classes and modules is a pain in the backside. But realizing what you were thinking when you wrote the function will save your butt in the future.

The function documentation is its contract

When you start the code by writing the documentation, you’re actually making a contract (probably with your future self): I’m saying this function does thisand this is what it does.

If later you find out that the code doesn’t match the documentation, you have a code problem, not a documentation problem.

If a function description includes an “and”, it’s wrong

Functions should do one thing and one thing only. When you’re writing the function documentation and find that you added an “and”, it means the function is doing more than one thing. Break that function into two and remove the “and”.

Don’t use Booleans as parameters

When you’re designing a function, you may be tempted to add a flag. Don’t do this.

Here, let me show you an example: Suppose you have a messaging system and you have a function that returns all the messages to an user, calledgetUserMessages. But there is a case where you need to return a summary of each message (say, the first paragraph) or the full message. So you add a flag/Boolean parameter called retrieveFullMessage.

Again, don’t do that.

‘Cause anyone reading your code will see getUserMessage(userId, true) and wonder what the heck that true means.

You can either rename the function to getUserMessageSummaries and have another getUserMessagesFull or something around those lines, but each function just call the original getUserMessage with true or false — but the interface to the outside of your class/module will still be clear.

But don’t add flags/Boolean parameters to your functions.

Beware of interface changes

In the point above, I mentioned about renaming the function. If you control the whole source where the function is used, that’s not issue, it’s just a matter of search and replace.

But if that function is actually exposed by a library, you shouldn’t change function names in a whim. That will break a lot of other applications beyond your control and make a lot of other people unhappy.

You can create the new functions and mark the current one as deprecated, either by documentation or by some code feature. Then, after a few released, you can finally kill the original function.

(A dickish move you can do is to create the new functions, mark the current function as deprecated and add a sleep at the start of the function, in a way that people using the old function are forced to update.)

Good languages come with integrated documentation

If the language comes with its own way of documenting functions/classes/modules/whatever and it comes even with the simplest doc generator, you can be sure that all the language functions/classes/modules/libraries/frameworks will have a good documentation (not great, but at least good).

Languages that do not have integrated documentation will, most of the time, have a bad documentation.

A language is much more than a language

A programming language is that thing that you write and make things “go”. But it has much more beyond special words: It has a build system, it has a dependency control system, it has a way of making tools/libraries/frameworks interact, it has a community, it has a way of dealing with people.

Don’t pick languages just ’cause they easier to use. Always remember that you may approve the syntax of a language for being that easy, but you’re also enabling the way maintainers deal with the community by choosing that language.

Sometimes, it’s better to let the application crash than do nothing

Although that sounds weird, it’s better to not add any error handling than silently capturing errors and doing nothing.

A sadly common pattern in Java is





This does nothing to deal with the exception — besides printing it, that is.

If you don’t know how to handle it, let it happen,so you can figure out whenit will happen.

If you know how to handle the issue, handle it

Counter-point to the previous point: If you know when something will raise an exception/error/result and you know how to handle it, handle it. Show an error message, try to save the data somewhere else, capture the user input in a log file to later processing, but handle it.

Types say what you data is

Memory is just a sequence of bytes; bytes are just numbers from 0 to 255; what those numbers mean is described on the language type system.

For example, in C, a char type of value 65 is most probably the letter “A”, which an int of value is 65 is the number 65.

Remember this when dealing with your data.

This is what most people get wrong about adding booleans to check the number of True values. Here, let me show you an example of JavaScript that I saw recently:





If your data has a schema, use a structure to keep it

You may be tempted to use a list (or tuple, if your language allows) to keep your data if it’s simple — like, say, only 2 fields.

But if you data has a schema — it has a fixed format — you should always use some structure to keep it, but it a struct or a class.

Understand and stay way of cargo cult

“Cargo cult” is the idea that, if someone else did, so can we. Most of the time, cargo cult is simply an “easy way out” of a problem: Why would we think about how to properly store our users if X did that?

“If BigCompany stores data like this, so can we”.

“If BigCompany is behind this, this is good.”

“Right tool for the job” is just to push an agenda

“Right tool for the job” should be an expression that meant that there is a right and a wrong tool to do something — e.g., using a certain language/framework instead of the current language/framework.

But every time I heard someone mention it, they were trying to push their favourite language/framework instead of, say, the right language/framework.

“The right tool” is more obvious than you think

Maybe you’re in a project that needs to process some text. Maybe you’re tempted to say “Let’s use Perl” ’cause you know that Perl is very strong in processing text.

What you’re missing: You’re working on a C shop. Everybody knows C, not Perl.

Sure, if it is a small, “on the corner” kind of project, it’s fine to be in Perl; if it is important for the company, it’s better that if it is a C project.

PS: Your hero project (more about it later in this doc) may fail due this.

Don’t mess with things outside your project

Sometimes people are tempted to, instead of using the proper extension tools, change external libraries/frameworks — for example, making changes directly into WordPress or Django.

This is an easy way to make the project unmaintainable really really fast. As soon as a new version is released, you’ll have to keep up your changes in sync with the main project and, pretty soon, you’ll find that the changes don’t apply anymore and you’ll leave the external project in an old version, full of security bugs.

Data flows beat patterns

(This is personal opinion) When you understand how the data must flow in your code, you’ll end up with better code than if you applied a bunch of design patterns.

Design patterns are used to describe solutions, not to find them

(Again, personal opinion) Most of the time I saw design patterns being applied, they were applied as a way to find a solution, so you end up twisting a solution — and, sometimes, the problem it self — to fit the pattern.

First, solve your problem; find a good solution; then you can check the patterns to know how you name that solution.

I saw this happens a lot: We have this problem; a design pattern gets close to the proper solution; let’s use the design pattern; now we need to add a lot of things around the proper solution to make it fit the pattern.

Learn the basics functional programming

You don’t need to go deep into “what is a monad” and “is this a functor”. But remember to not keep changing your data all the time, create a new element with the new values (treat your data as immutable) and make functions/classes that don’t keep some internal state (pure functions/classes) if possible.

Cognitive Cost is the readability killer

Cognitive dissonance” is a fancy way of saying “I need to remember two (or more) different things at the same time to understand this.” Keeping those different things in your head creates a cost and it keeps accumulating the more indirect the things are (’cause you’ll have to keep all those in your head).

For example, adding booleans to count the number of True values is a mild cognitive dissonance; if you’re reading a piece of code and see a sum()function, which you know makes the sum of all numbers in a list, you’d expect the list to be composed of numbers, but I’ve seen people using sum() to count number of True values in a list of booleans, which is confusing as heck.

The Magical Number Seven, Plus or Minus Two

The magical number” is a psychology article about the number of things one can keep in their mind at the same time.

If you have a function, that calls a function, that calls a function, that calls a function, that calls a function, that calls function, you may be sure it will be a hell to read later.

Think more about: I’ll get the result of this function, then pass it to the second function, get its result, pass to the third an so on.

But:

  1. Today, psychologists talk more about the magical number FOUR, not seven.
  2. Think function composition (as in “I’ll call that function, then that function, then that function…”), not function calling (as in “That function will call that function, that will call that function…”).

Shortcuts are nice, but only in the short run

A lot of languages/libraries/frameworks add a way to make things shorter, reducing the number of things you need to type.

But, later, that will bite you and you’ll have to remove the shortcut and do the long things.

So learn what the shortcut does before using it.

You don’t need to write things the hard way first and then clean up using the shortcuts: All you need to do is what the shortcut does in the background, so you at least have knowledge of what can go wrong using it, or how to replace it with the non-shortcut version.

Resist the temptation of “easy”

Sure that IDE will help you with a ton of autocomplete stuff and let you easily build your project, but do you understand what’s going on?

Do you understand how your build system works? If you had to run it without the IDE, would you know how?

Can you remember your function names without autocomplete? Isn’t there a way to break/rename things to make them easier to understand?

Be curious about what goes behind the curtains.

ALWAYS use timezones with your dates

When dealing with dates, always always add the timezone with it. There will be always a problem with your computer timezone and the production server timezone (or one of the instances timezones) and you’ll lose a lot of time trying to debug what the heck the interface is showing the wrong time.

ALWAYS use UTF-8

The same problem you’ll have with dates, you’ll have with character encoding. So always convert your strings to UTF8; save them in the database as UTF8; return UTF8 on your APIs.

(You may convert to any other encoding, but UTF8 won the encoding wars, so it is easier to keep it this way.)

Start stupid

One way to get away from the IDE is to “start stupid”: Just get the compiler and get an editor (ANY editor) with code highlight and do your thing: Code, build it, run it.

No, it’s not easy. But when you jump into some IDE, you’ll think of buttons of simply “Yeah, it runs that” (which is exactly what IDEs do, by the way.)

Logs are for events, not user interface

For a long time, I used logs to show the user whatever was happening — ’cause, you know, it’s a lot easier to use a single thing instead of two.

Use the standard output to inform the user of events, standard err to inform the user about errors but use logs to capture something that you can later process easily.

Think about logs of something you’ll have to parse to extract some information at that time, not user interface; it doesn’t have to be human-readable.

Debuggers are over-rated

I heard a lot of people complaining that code editors that don’t come with debugging are terrible, exactly because they don’t come with debugging.

But when your code is in production, you can’t run your favorite debugger. Heck, you can’t even run your favourite IDE. But logging… Logging runs everywhere. You may not have the information you want at the time of the crash (different logging levels, for example) but you can enable logging to figure out something later.

(Not saying debuggers are bad, they just not as helpful as most people would think.)

Always use a Version Control System

“This is my stupid application that I just want to learn something” is not even a good excuse to not use a version control system.

If you start using a VCS right from the start, it will be easier to roll back when you do something stupid.

One commit per change

I’ve seen people writing commit messages like “Fixes issues #1, #2 and #3”. Unless all those issues are duplicates — in which two of those should be already closed — they should be 3 commits, not one.

Try to keep a change in a single commit (and by change I don’t mean “one file change”; if a change requires changes in three files, you should commit those three files together. Think “if I revert this back, what must go away?”)

“git add -p” is your friend when you overchange

(Git topic only) Git allows merging a file partially with “-p”. This allows you to pick only the related changes and leave the other behind — probably for a new commit.

Organize projects by data/type, not functionality

Most projects keep an organization like:





in other words, they keep data organized by functionality (all the incoming models are in the same directory/package, all the filters are in the same directory/package and so on).

This is fine and works. But when you organize by data, it’ll make a lot easier to split your project in smaller projects — ’cause, at some point, you may want to do almost the same thing as you’re doing right now, but with small differences.





Now you can make a module that deals only with Data1, another that works only with Data2 and so on. And then you can break them into isolated modules.

And then when you have another project that also have Data1 but also deals with Data3, you can reuse most of the stuff in the Data1 module.

Create libraries

I’ve seen a lot of projects that either make a mega repository with different projects or keep different branches that instead of just being a temporary environment for later joining the main development area, are just to keep that small, different thing going (picking the point above about modularization, imagine that instead of building a new project that reuse the Data1 type, I have a branch that has a completely different main function and the Data3 type).

Why not split the common parts into libraries and require it in different projects?

The reason is, most of the time, ’cause people don’t know how to either create libraries or they worry how they are goint to “publish” those libraries into the dependency sources without giving it around (so maybe it’s a good idea to also understand how your project management tool retrieves dependencies, so you can create your own dependency repository).

Learn to monitor

On a previous life, to understand how a system behaved, I added a ton of metrics: how fast things were going in, how fast things were going out, how many things were in the middle, how many the job processed…

It gives a really good view of how a system is behaving. Is the speed going down? If it is, I can check what is going into the system to understand why. Is it normal going down at some point?

Thing is, after this, it is really weird trying to figure out how “healthy” a system without any monitoring is after that. Checking a system health with just “Is it answering requests” doesn’t fly anymore.

Adding monitoring early will help you understand how your system behaves.

The config file is friend

Imagine you wrote a function that you have to pass a value for it to start processing (say, a twitter user account id). But then you have to do that with two values and you just call the function again with the other value.

It makes more sense to use a config file and just run the application twice with two different config files.

Command line options are weird, but helpful

If you move things to config files, you could also help your users by adding an option to select the config file and expose it.

There are libraries to handling command line options for every language today, which will help you into building a good command line and giving your users a standard interface for everything.

Not just function composition, but application composition

Unix came with the idea of “applications that do one thing and do it well”.

Now, I said you could use one application with two config files, but what if you need the result of both applications?

That’s when you can write an application that reads the results of the first one with both config files) and turn into a single result.

Even for app composition, start stupid

Application composition may lead to microservices — which is good — but microservices require some ideas about how applications “talk” between them over the wire (protocols and such).

You don’t need to start with that. Both applications can write and read from files, which is way easier.

Worry about talking over the wire later, when you understand how networks work.

Optimization is for compilers

Let’s say you need more performance. You may be tempted to look at your code and thing “where I can squeeze a little bit more performance here” or “How can I remove a few cycles here to get more speed”.

Well, guess what? Compilers know how to do that. Smarted compilers can even delete your code ’cause it will always generate the same result.

What you need to do is think a better design for your code, not how to improve the current code.

Code is humans to read. ALWAYS. Optimization is what compilers do. So find a smarted way to explain what you’re trying to do (in code) instead of using shorter words.

By lazy (evaluated)

A long time ago, a small language made the rounds by not evaluating expressions when they appeared, but when they were needed.

Lisp did this a long time ago, and now most languages are getting it too.

For example, Python have the yield statement, which will stop the execution of the current function and return the value immediately, yielding a new value only when the function is called again. If you chain functions that keepyielding results, you won’t need as much memory as functions that keep returning lists.

On a Team/Work

Code reviews are not for style

Take your time on code reviews to point architectural or design problems, not code style problems. Nobody really likes the person whose code reviews are only “you left blanks in this line” or “missing space before parenthesis” and such.

Now, if you do find architectural or design problems, then you can add your code style problems.

Code formatting tools are ok, but they are no silver bullet

One thing a team may be tempted to do to avoid discussing style in code reviews is to use a code formatting tool to auto-format code before committing.

Now yeah, that kinda solves the problem, but there is one small problem: we, humans, are not as flexible to read code as computers are; what is readable by a computer may not be readable by a human. Surely they try to create some heuristics on what is good for human reading, but that doesn’t mean it gets right.

If you do use a code formatting tool, use it to find out where it changes the code the most; you probably need to simplify that part of the code to avoid it messing so much.

Code style: Follow it

If your project have a defined code style, you must follow it. Sometimes it may not be clear (“this struct/class should be singular or plural”?), but do your best to follow it.

… unless that code style is the Google Code style

(Totally personal opinion, feel free to disagree) Every freaking time Google comes with their own coding style, it’s a garbage fire. The community came with a better style way before and Google seem to come with a style with high contrasting parts just to call it theirs.

There is only one coding style for C/C++: K&R

(Totally personal opinion again) Every other coding style is WRONG. 🙂

There is only one coding style for Python: PEP8

The community (most of it) writes code in PEP8. Follow it and your code smoothly integrate with the rest of the ecosystem.

Explicit is better than implicit

You know what’s one of the worst function names ever? sleep().

Sleep for how long? It is seconds or milliseconds?

Be explicit with what you use; sleepForSecs and sleepForMs are not perfect, but are better than sleep.

(Think about this when you’re writing your app command line interface or its config file.)

(I could throw the whole “Zen of Python” here, but I’m trying to focus on personal, direct experience.)

Companies look for specialists but keep generalists longer

If you know a lot about one single language, it may make it easier to get a job, but in the long run, language usage dies and you’ll need to find something else. Knowing a bit about a lot of other languages helps in the long run, not to mention that may help you think of better solutions.

“A language that doesn’t affect the way you think about programming, is not worth knowing.” — Alan Perlis

For a long time, I kept a simple programming rule: The language I’m playing at home should not be the same language I’m using at work. This allowed me to learn new things that later I applied in the work codebase.

I learnt how generics work in Java by writing Rust code; I understood how Spring does dependency injection by reading how to do it in C++.

Think of the users

Think how the data you’re collecting from your users will be used — this is more prevalent on these days, where “privacy” is a premium.

If you capture any used data, remember to protect it against unauthorized use.

The best secure way to deal with user data is not to capture it

You can be sure that, at some point, the data will leak, either by some security flaw or human interference.

If you don’t capture any user data — or store it in anonymized way — you won’t have any problems.

Keep a record of “stupid errors that took me more than 1 hour to solve”

I tried but never managed to create a list of stupid errors I kept finding that took more than 1 hour to solve it, which were simply “forgot to add dependency” or “add annotation”, mostly because there was more than once that I kept fighting some stupid error for more than 1 hour.

But you should try to keep a list of stupid errors that took you 1 hour to solve, ’cause later you can use it to not stay more than 1 hour to solve some stupid error.

If it doesn’t run on your computer, you have a problem

I’ve seen a lot of systems that would never run on a isolated computer, like the developer tool, ’cause the system requires running on a specialized environment.

This is something that really kills productivity.

If your system will run on a specialized environment — and I’m including “the cloud” here — look for something that can abstract whatever you’re using. For example, if you’re using AWS SQS, which is a queue, look for a library that can abstract the way a queue works so you can also run with RabbitMQ, which can be easily run on your own computer.

If you’re using a very specialized thing, you may have to write the abstraction yourself, isolating it from the main system, so you can develop the main product in peace.

Personal

When it’s time to stop, it’s time to stop

Learn when you can’t code anymore. Learn when you can’t process things anymore. Don’t push beyond that, it will just make things worse in the future.

I tried to keep coding once when I had a migraine (not strong, but not mild). Next day, when I was better, I had to rewrite most of the stuff I did, ’cause it was all shit.

Code of conduct protect you, not them

When you’re beginning with any language/library/framework, check their CoC; they will protect you from being harassed for not immediately getting what is going on instead of blocking you from telling them what you think.

I’m mentioning this ’cause a lot of people complain about CoC, but they forget that they allow them to join in any project without being called “freaking noob” or “just go read the docs before annoying us”.

Also, remember that most people that are against CoCs are the ones that want to be able to call names on everyone.

Learn to say no

Sometimes, you’ll have to say no: No, I can’t do it; no, it can’t be made in this time; no, I don’t feel capable of doing this; no, I don’t feel comfortable writing this.

Once I had to say to our CTO: “Ok, I’ll do it, but I want to note that I don’t agree with what we are doing.” In the end, the app was barred exactly because the thing we were doing.

You’re responsible for the use of your code

This is hard. Very very hard. It’s the difference between “freedom” and “responsibility”.

There is nothing wrong in writing, for example, a software to capture people’s faces and detect their ethnicity, but you have to think about what that will be used on.

Don’t tell “It’s done” when it’s not

You are tired of running the same thing over and over again. You kinda remember that something weird may happen, but because you’re tired, you tell everyone that “It’s finished”.

Don’t do that.

Someone will try that weird case on the first run and immediately tell you that it is not working.

You’ll learn about yourself the hard way

We get frustrated with code that doesn’t compile. We get angry with customers asking things back and forth.

And we lash out on other when that happens.

And that will get you in trouble.

It happens.

People get pissed/annoyed about code/architecture because they care

You’ll find yourself in the other side of the coin: You’ll describe some solution and people will seem annoyed/pissed about some solution.

When people care about a product/code, they do that.

“Yeah, you don’t like that hushed solution ’cause you care” was one of the nicest things someone told about myself.

Learn from your troubles

You’ll get annoyed, pissed, frustrated, and angry. You’ll get you in trouble. You’ll see people getting in trouble because of this kind of stuff.

You must learn about it. Don’t ignore it.

One thing I learnt the hard way was that I get really aggressive when I’m frustrated. Now, when I notice I start to get frustrated, I ask help from someone else. It’s really therapeutic to see that someone else also struggles with your problem, and that’s not just you.

Pay attention on how people react to you

I have a “angry man resting face” kind of face.

Sometimes I’ll ask things and people will move a bit back — like I’m telling them their solution is wrong.

That’s when I have to add “I’m not saying it’s wrong, I’m just confused”.

That may help you to not get in trouble.

Learn to recognize toxic people; stay away from them

You’ll find people that, even if they don’t small talk you, they will bad mouth everything else — even some other people — openly.

Stay away from those people.

You have no idea how that kind of attitude will drive you down.

Beware of micro-aggressions

“Micro-aggressions” are aggressive comments in small doses. Like someone that keeps calling you “that person” or seemingly innocuous comments about your position in some policy.

Those are hard to fight, ’cause PR won’t listen to you saying that they are attacking you. Also, they are hard to detect, ’cause they seem small enough, but they do pile up and you’ll blow your anger all at once.

Better just stay away and avoid contact as possible.

No, I don’t think they are “fixable”

(Personal opinion) Someone could say “Hey, maybe if you spoke to that person, they would stop”.

Personally, I don’t think they would. This kind of stuff is going for so long to them that it feels natural and, most of the time, you’re the wrong one (for not seeing that they are joking, for example, in true “Schrödinger’s asshole” style.)

Toxic/micro-aggressors are only fixable if they are YOU

Unless it’s you realizing you’re acting like a toxic person or micro-attacking someone, and realize that you’re actually doing more harm than good being that way, there is no way to fix those traits (again, personal opinion).

…mostly ’cause hearing from someone else may feel “they are the ones against me!” to them.

Hero Projects: You’ll have to do it someday

An “hero project” is a project/spec change/framework that you personally think will solve a group of problems in your project. It could be a different architecture, a new framework or even a new language.

That means you’ll spent your free time to write something that is already being worked/exists just to prove a point.

Sometimes it proves you where wrong.

(But you got something from it, nonetheless.)

Don’t confuse “hero project” with “hero syndrome”

I have seen this at least two times: Someone claims things don’t work when they aren’t around or that they don’t need help.

This is “hero syndrome”, the idea that that person is the only one capable of solving all the problems.

Don’t be that person.

Learn when to quit

You tell your boss that you didn’t finish on time because something weird happened and he lashed out at you.

One of your coworkers is constantly micro-attacking you.

Another one is the guy that keeps doing stupid pranks, saying bullshit and small talking other groups all the time.

A third is always complaining that when he’s not around, things don’t work.

It’s time to start sending your resume around, no matter how good the pay is or how awesome the project is.

… unless you want to be a constantly pissed off, annoyed person when you’re in the forties.

I.T. world is a very small egg

We have a expression here: “The world of something is a small egg”, which means that you don’t live in a large world; the world is small.

I.T. world is really small.

The person you work with today will find you again in 15 years after you both changed 3 or 4 jobs already.

And you’ll meet a lot of other I.T. people in the way.

And they will talk about themselves.

And whatever you say/do will be talked around, which one person will hear and pass along another company, which will pass along other people, which will pass the story along to another company and, suddenly, when you realized, nobody will hire you locally ’cause everybody knows that time when you fucked up a project or punched a colleague in the face.

Paper notes are actually helpful

I tried to become “paperless” many times. At some point, I did keep the papers away, but in the very end, it really do help to have a small notebook and a pen right next to you write that damn URL you need to send the data.

Trello is cool and all, but Post-its are nicer

Nothing says “I’m really busy, but organized” like having a bunch of post-its on your desk.

Blogging about your stupid solution is still better than being quiet

You may feel “I’m not start enough to talk about this” or “This must be so stupid I shouldn’t talk about it”.

Create a blog. Post about your stupid solutions. They are still smarter than someone else’s solution.

Also, come back later and fight your own solutions with better ones.

Show your growth.

On top of that, they help you keep small notes or things you need to do.

… but turn off the comments

One thing about posting your stupid solution is that it will attract people who just want to mess with you. “This is stupid”, for example. “Your dumb” may someone say, unaware of who’s actually dumb.

Turn it off. Don’t let those people stop you.

Post your stupid solution online

Don’t keep a Github only for those “cool, almost perfect” projects. You’re free to show that, at some point, you were a beginner.

You can always come back and improve your code.

(Or don’t: I still have a public repo of my first Python project that looks like I just translated Java into Python, without the Pythonic part.)

Keep a list of “Things I Don’t Know”

Richard Feymann, famous physicist, kept a notebook with the title “Things I Don’t Know”.

When you find something that seems cool and you’d like to know more, create a file/note/whatever with it in the title. Then make notes about what you find/figure out.

GoCN每日新闻(2019-07-03)

1. Go并发编程与同步原语 https://draveness.me/golang-sync-primitives.html

2. Go Modules踩坑总结 https://juejin.im/post/5d1ae1b2f265da1b8466fecb

3. 彻底弄懂return和defer的微妙关系 https://juejin.im/post/5d173ce16fb9a07ea803df75

4. net/http输出context引起的map panic http://xiaorui.cc/?p=5919

5. []byte和string类型相互转换时的性能分析和优化 https://www.pengrl.com/p/31544/

编辑: 周云轩

订阅新闻: http://tinyletter.com/gocn

GoCN归档: https://gocn.vip/question/3544

GoCN每日新闻(2019-07-02)

1. Go 实现的广告拦截工具:https://github.com/kaepora/resilience 

2. Go 压缩/解压缩文件: https://github.com/mholt/archiver

3. Go vs Python: 选择适合你的语言 https://medium.com/swlh/python-vs-golang-select-the-best-one-to-level-up-your-business-1a6d0fb32991

4. 企业构建 Serverless 团队的五个建议:https://thenewstack.io/five-tips-building-serverless-teams-enterprise

5. 使用 AWS Lambda 构建 PDF 生成器:https://medium.com/@_rich/richard-keller-61d9cb0f430 

编辑: 薛锦

订阅新闻: http://tinyletter.com/gocn

GoCN归档:https://gocn.vip/question/3541

GoCN每日新闻(2019-07-01)

1. 微服务系列(一):Go Rpc 源码解读 https://juejin.im/post/5d1760455188255cfc1a019f

2. 记一次 goroutine 泄漏问题查找原因与解决 https://github.com/cdongyang/note/blob/master/go/goroutine-leak.md

3. 使用git操作svn仓库 https://tonybai.com/2019/06/25/using-git-with-svn-repo

4. Excelize发布2.0.1版本, Go语言最受欢迎的Excel基础库 https://mp.weixin.qq.com/s/LmIBHOEjAK7N9oru6TeT5A

5. 开源项目之个人视频流服务器 tube https://github.com/wybiral/tube

编辑: 宋佳洋

订阅新闻: http://tinyletter.com/gocn

GoCN归档:https://gocn.vip/question/3540

GoCN每日新闻(2019-06-30)

1. 关于改进 “if err != nil” 的讨论 https://github.com/golang/go/issues/32825

2. 为 Go 开发者准备的 Makefiles 教程 https://www.youtube.com/watch?v=QztvWSCbQLU

3. gRPC+gRPC Gateway 能不能不用证书?https://github.com/EDDYCJY/blog/blob/master/golang/2019-06-22-grpc-gateway-tls.md

4. 还原 panic 时的函数信息 https://lekstu.ga/posts/pclntab-function-recovery/

5. 性能持续测试工具 performabot https://github.com/saschagrunert/performabot

编辑: lwhile

订阅新闻: http://tinyletter.com/gocn

GoCN归档:https://gocn.vip/question/3539

GoCN每日新闻(2019-06-29)

1. 提案:内置的Go错误检查 https://go.googlesource.com/proposal/+/master/design/32437-try-builtin.md

2. Go Modules 语义版本控制的问题 https://blog.dgraph.io/post/serialization-versioning

3. 尝试更严格的gofmt https://www.reddit.com/r/golang/comments/c66cz2/experimenting_with_a_stricter_gofmt

4. 减少类型层次 https://www.ardanlabs.com/blog/2016/10/reducing-type-hierarchies.html

5. 分布式时序数据库 LinDB https://zhuanlan.zhihu.com/p/35998778

编辑: 马怀博 

订阅新闻: http://tinyletter.com/gocn

GoCN归档:https://gocn.vip/question/3538

GoCN每日新闻(2019-06-28)

1. 关于内置catch函数捕获错误的讨论 https://github.com/golang/go/issues/32811

2. Go单元测试 https://levelup.gitconnected.com/unit-testing-in-go-205ada2b9d7c

3. Go defer 会有性能损耗,尽量不要用?https://github.com/EDDYCJY/blog/blob/master/golang/pkg/2019-06-16-Go-defer-loss.md

4. 如何快速提升 Go 程序性能? https://mp.weixin.qq.com/s/rta0Prdc5xq7Zd7mLzvcWA

5. Go Modules踩坑总结 https://mp.weixin.qq.com/s/2v8kGm8T9BQFmpLfQE7-wg

编辑: yulibaozi

订阅新闻: http://tinyletter.com/gocn

GoCN归档:https://gocn.vip/question/3537

GoCN每日新闻(2019-06-27)

1. 走向Go 2的下一步 https://blog.golang.org/go2-next-steps

2. 使用Go构建数据库密集型应用程序的终极指南 http://t.cn/AipRdZir

3. 关于在gRPC中使用TLS的 http://gophersre.com/2019/06/21/grpc-dont-supply-a-client-cert/

4. 经典并发模式 https://www.youtube.com/watch?v=5zXAHh5tJqQ

5. 内存泄漏优化 https://segmentfault.com/a/1190000019591222

编辑: 李森森

订阅新闻: http://tinyletter.com/gocn

GoCN归档:https://gocn.vip/question/3536