今日推荐开源项目：《假装古人 wenyan-lang》
今日推荐英文原文：《5 Rules of Code》
今日推荐开源项目：《假装古人 wenyan-lang》传送门：GitHub链接
推荐理由：要想让程序看起来很古人，那当然就是用文言文啊，不过这次要用更古老的办法——直接用文言文来编程。这个项目设计了文言文的编程语法，让你可以直接使用文言文完成在普通编程语言里能做的大部分事情（虽然有点麻烦），然后你就可以写个程序，再命个名，就能拿出去当一篇你写过的文言文了，虽然读起来可能有点奇怪和不通顺，但是意思可以说传达的很到位。
今日推荐英文原文：《5 Rules of Code》作者：Peter Christian Fraedrich
原文链接：https://medium.com/better-programming/5-rules-of-code-6970a55a444b
推荐理由：作者对于编码过程中的经验总结
5 Rules of Code
Rules for maintaining your code and your sanity as a modern developer
Over the past little while, I’ve compiled a list of “commandments”: things you must and must not do as a modern developer. Let’s walk through five of them and discuss why you should adopt them for yourself and your teams too.1. Monorepos: Just Don’t
If you’re not familiar with the concept of a monorepo (I envy you) then let me explain: instead of having multiple source-code repositories for your applications, the monorepo concept places everything in a single repository.This can make contributing to multiple projects easier, but it comes at a cost: you must use subversion, you cannot use Git. Git, for all its strengths, does not support sparse checkouts like subversion.
Sparse checkouts allow you to check out individual directories of a larger tree instead of the whole tree as Git does. This means you can have multiple people or teams work on individual parts of a tree without overlap.
You cannot to this with Git and therefore should use individual repositories for discrete applications when using Git as your source control.
2. Problem First, Then Solution.
Everyone has their go-to things they like to use: Redis, MySQL, etc. And that’s OK, having preferences is healthy and normal.But we run into trouble when those preferences become requirements; a lens through which every problem is viewed that cannot be deviated from. And let’s not be deceived, this is more than just an individual vice, organizations are guilty of this too.
Lots of companies mandate certain technologies, libraries, or tools, often with little thought or input from the “boots on the ground”, developers and operations engineers who have to actually use or implement these technologies.
This is part of my long-standing gripe with enterprise architecture groups and their God-like powers over the mere mortals who actually write the code.
Oftentimes, it’s the architecture group that decides that the company is going to use a certain technology or product — Kubernetes, OpenShift, AWS, etc. — without fully understanding the problems inside the organization and what these technologies were designed to solve.
I saw this personally during my time at Capital One where our architecture group decided that we were going to be a Kubernetes company but didn’t have any real sense of what that meant to those of us who had to actually develop and implement the systems and tooling around it, or the applications that would run on it.
And it was often architecture (or their malnourished stepbrothers, enterprise security) that were the cause of a lot of the roadblocks to them getting what they wanted.
Had they — both architecture and security — understood the problems that needed to be solved first before deciding what tools to use second, then things might have gone very differently and most likely a whole lot smoother.
3. Ask Questions
It sounds so easy. So simple. So childish. Yet, so hard. Don’t understand something? Ask questions. Want to know why something is the way it is? Ask questions. Want to know where the project is headed? Ask questions.Just because you ask doesn’t mean you are going to get the answer you want, or any answer at all, but if you don’t ask questions then you’ll never find out.
One of the best things to do after coming to a new team or starting a new job is to ask all the questions. Pulling the FNG card is like having a “get out of looking stupid” card for the first little while.
Asking questions that start with: “Hey, I’m new to all of this, so let me ask what might be a dumb question…” is an awesome way to find out things you want to know but also challenge the status quo.
You’d be surprised to find out how many organizations are doing things a certain way “because reasons”. Usually, it’s because someone set it up that way a while ago and no one bothered to go back and fix it.
By asking questions, challenging assumptions, and digging for information, we make our teams, our groups, ourselves, and our lives better. I’ve been able to cut out entire layers from infrastructures from asking questions like this.
Who knows what you’ll be able to trim out.
4. Square Pegs Don’t Go in Round Holes
Like a lot of good things — making love, team chemistry, precision-threaded machine screws — when it’s good it feels effortless. Our lives are filled with feedback, explicit or not.The way your keyboard feels under your fingers as you type, the little vibration “click” your phone does when you press a flat imaginary button, the way my lactose-intolerant stomach revolts every time I decide that having ice cream is 100% worth it; these are all forms of feedback.
They let us know when something is going well, normal, or going very, very badly, and it’s the same for literally everything. We’ve all been there before, working on a project, that nagging feeling in the pit of our stomach that keeps telling us that we should change databases to better support our data model.
That, instead of writing a lot of fragile data transformation code, you could do a lot of this in-database if you just used a relational database and an ORM. Or, after finding yourself on a new team or in a new job and you just don’t get along with your peers for some reason.
It’s not that you don’t like them or they don’t like you, some personalities just work better together than others. Don’t force it. Find the better solution and go with that.
Talk to your manager about changing teams. Find an ORM and get to work. Stop what you’re doing and do the thing that’s going to make it effortless. Leave the square-peg/round-hole problems to the NASA nerds.
5. Use the Best Tool for the Job (Unless Its Java)
I’m probably going to get a lot of hate for saying this, but I don’t see a reason to be using Java in today’s industry.Java does have some differentiators against its competition, I won’t deny that, but those differentiators don’t really apply to today’s engineering environments. Here are some pros for using Java:
- It can run anywhere.
- Automatic memory management (with its garbage collector).
- Extensive community and frameworks/libraries/plugins for the JVM stack.
And today, Java isn’t nearly as unique in the memory management space, either. Both Go and Rust have some sort of garbage collection, Python uses reference counting, and many other languages do as well.
And Java is by far not the only language with large active communities around it. Rust and Python have incredibly active and helpful communities, with Go’s community ramping every day.
But the other trade-offs you make with Java, at least in my opinion, aren’t worth it. Because Java relies on the JVM, there is an automatic size cost incurred with every Java application.
This might not be much of a consideration when talking about servers that have gigabytes of free space — a couple of hundred MB’s aren’t much — but in a highly containerized world a few hundred MB is astronomical. (Note that Python suffers from this downside as well.)
With compiled, statically-linked languages like Go and Rust (and others), you can have very small, very lean containers that often have a single binary in them, with sizes as small as 4 MB.
This is important especially for large organizations where network throughput is a premium, downloading a new container that’s 400 MB or 5 MB is an easy choice to make.
Also, because of the JVM and that Java is JIT-compiled, there is a performance cost to running Java code.
For low-latency, high-throughput applications, or scenarios where bin packing a server is extremely important, losing performance to the overhead of translating bytecode to system calls just isn’t worth it.
All of this is why it’s important to use the right tool for the job at hand.
You don’t want to use BASIC for landing someone on the moon, and you don’t want to use Java for high-performance computing — find the solution that matches the problem you’re trying to solve.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
Mr. Podcast is great. He delivers information instantly, and you can do many other things while listening to him.
Here’s Mrs. Video.
She’s an amazing educational resource, and has the ability to condense difficult concepts into digestible pieces. She makes learning fun, and makes you feel like a kid again when you hang out.
Finally, meet Mr. Book.
He’s the sage of the group, and has been around for quite some time. So when you’re with him, he’d like a little respect.
You love Mr. Podcast, Mrs. Video, and Mr. Book.
This feels great, but at some point, your mind starts getting a little… full.
You feel it loading up, but you tell yourself that you must keep going. You can never have enough knowledge, and it’s so easy to acquire anyway.
This brain fuel keeps pouring in…
Until one day, you feel fucking nauseous.
The mind is just like the stomach. Give it too much stuff without the proper release, and you’ll get sick.
This ratio he spoke of was an elegant way of framing the problem at hand, while also delivering a solution.
The rate of release is determined by our ratio. The higher it is, the more fuel is processed and poured out. The lower it is, the less fuel is utilized, and the more knowledge remains in your head.
But as we described earlier, a tightly shut valve leads to a restless mind. Having all this information without the proper release is discomforting.
So the first step is simple: keep the Release Ratio above zero, no matter how small that number is.
It doesn’t matter if the Release Ratio is 0.1 or 0.001. Start small. Make something that just takes five to 10 minutes of your day — possibly even less. All that matters is that the valve is cracked open.
Like most things worthwhile, the hardest part is the start. But remember, all you need to do is to keep the Release Ratio above zero. That’s the golden rule. Once you’re able to do that consistently, then you’re ready for the next step.
This is an awesome thing, and I can validate this through personal experience.
At this stage, you’re spending hours each day creating things, not minutes. Your mind container is being emptied out at a rate that allows for more brain fuel to come in, and this all feels healthy and productive.
This is a scenario in which the Release Ratio is greater than 1.0, or when you create more than you consume. This is common amongst full-time content creators: writers, artists, designers, entrepreneurs, etc. In fact, it’s probably the default setting for this group of folks.
When the mind container is empty, there is nothing to draw upon. You can try to create stuff without brain fuel, but the quality of what you make will suffer.
Like all things worthwhile, there’s an intricate balance to consider. Being a knowledge sponge is fun, but you need the proper release to make it meaningful. Release too much without refilling, however, and you’ll be a wiry ball of fatigue.v
If you enjoyed this post, consider joining the More To That email list.
