开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《不拘一格 Blotter》
今日推荐英文原文：《Use the 33% Rule to Change Yourself as a Programmer》

---

今日推荐开源项目：《不拘一格 Blotter》传送门：项目链接
推荐理由：这个 JS 库可以帮你把文字用各种你想得到或者完全没想过的方式渲染出来，在项目的官网上就有各种各样的文字效果，包括首页上那个极度吸引人眼球（甚至到了看久一点可能会眼睛痛的程度）的标题。缺点也很明显，如果不选用字体而是自定义各种花里胡哨的效果给网页上大篇幅的文字，它们将会全部成为 canvas 元素而不能被用户像平时一样选中。

---

今日推荐英文原文：《Use the 33% Rule to Change Yourself as a Programmer》作者：Nuha Khaled
原文链接：https://medium.com/better-programming/use-the-33-rule-to-change-yourself-as-a-programmer-5fe296cb16a3
推荐理由：一种新的用于分配花在每件事上时间的方法，一部分用于挑战，一部分用于放松

Use the 33% Rule to Change Yourself as a Programmer

Little changes leave lasting impacts

When I was younger, I used to watch a lot of TED Talks, and I remember this talk by Tai Lopez about the 33% Rule. I loved it and I started to apply it to my programming life. I think it’s time to share it with other programmers.

What is the 33% Rule?

It basically states that 33% of your time should be spent with mentors (people that challenge you), 33% with your peers (those on the same level as you), and 33% with people who you can mentor and guide.

This idea is not just applied to “time” and “people,” it is applied to almost everything. When we’re students, it is easy to know what to do and balance this thing with the other few things we do in our life. Yet, we get older, we have more responsibilities, and more things that we want to be successful at, and there is the balance problem.

This balance problem is not just about doing all that you want to do. It’s also about staying active and alive and not falling into a routine.

So, I find that dividing what you do according to how challenging it is, is smart! So, you want to divide your time into three parts:

• Challenging part.
• Comfort-zone part.
• Normal part (sometimes challenging, sometimes not).

What I love about this rule, is that it pushes you to be the action, not the reaction. It asks you to put more focus on choosing and monitoring what you are doing in life. Let’s look at some examples.

1. Projects

At the beginning of our programming life, we normally get busy with projects that challenge us. By the time we grow up older and have more experience, we start to work on stuff that’s less challenging — in our comfort zone.

To follow the 33% rule, you decide to do more side-projects that help you to stay on track. For example, if you’re an experienced programmer working full-time, instead of just working on the daily normal projects that aren’t challenging anymore, make sure to put yourself on more challenging projects as well. So, let’s say you are a web developer — start making machine learning projects with the knowledge you already have.

If you’re a fresh graduate and everything is challenging for you, try to find projects that are easy and in your comfort zone. The rule is not just about searching for challenges, it is to find the balance.

So balance your projects between:

• Challenging: Find projects you don’t know how to do yet, and start doing.
• Comfort zone: Do projects you are already very good at, freelance, volunteer, and try to always stay experienced at what you are already experienced at.
• Normal part: The normal part, is the project we usually all do, sometimes challenging, sometimes noy.

2. Learning

When we are students we try to learn almost everything, but later, after graduation, we focus on just one thing. In the beginning, as a fresh graduate, you will learn a lot more, but with time you can get into your comfort zone. What I need you to do is:

• Challenging: Learn something really new, maybe a new field. So if you do web development, start checking mobile development for example.
• Comfort Zone: If you a Java developer, keep learning more about Java, don’t stop learning. This learning will make you more experienced. Read articles, check out courses and look at everything you can on daily basis. Steady long learning helps you go deeper and deeper in something you are already comfortable in.
• Normal part: Learn general tech knowledge, and learn various new things that sometimes will challenge you, and sometimes no.

You will be a life-time learner who is getting deeper at what they know. Find out about new things and challenge yourself from time to time.

3. Reading

Same as learning, reading is challenging when we grow older. When we were very young, reading novels would be all that we think about. Later, we discover how useful reading is, yet we get distracted by how much we want to read. We want to read tech books, self-enhancing books, parenting books, religious books, and almost every book out there.

Even if we decide to just read programming-related books, we get confused about what to read. Should I read about clean code to get my code cleaner, or a new challenging field book, or startups? It is very frustrating to waste time choosing.

The 33% rule helped me to decide to keep more than one book open in parallel and to consider them as different activities. I read in three categories:

• Challenging: I choose a challenging book, it would be a book that needs a great focus.
• Comfort Zone: I choose a book that I will enjoy far away from how much it would be useful or would have a high impact. It is a book that I would read while having a headache to relax, unlike the challenging one.
• Normal book: A book that is a mixture of both.

4. Friends

Choosing the right friends doesn’t just help you to be a better programmer, it helps you to be more balanced. Some people start to lose all social relationships with time and get stuck with work-mates only. Others don’t have friends that will inspire them in their programming field. Do yourself a favor and start thinking about your relationships as soon as you can. Divide people you know into these categories:

• Challenging: Keep in touch and maintain a good relationship with people who mentor you — those who you return to for advice in hard times, who inspire you to do more, and who you look up to. For programming-related relationships, you can find these people as teammates where you work, in conferences, and in places where you learn, like courses or workshops.
• Comfort-zone: This category is for friends that you enjoy being around, as simple as that. Always make sure to balance your life to meet them more and get in touch. If you want to apply this rule to programming-related people only, then let these people be those who you inspire and mentor.
• Normal-zone: This category is for normal people you meet daily at work, courses, or even online. those people who have something to give sometimes, and something to learn from you as well.

5. Time You Spend Online

Our generation spends a lot of time online. The way we spend our time will affect how our lives turn out. Make sure to balance it. Adding things that are challenging and useful to your daily free-time routine will help you to upgrade. The key is to change how you view free time:

• Challenging: Find time every day on things like Hackerrank, Leetcode, or any other challenging activity. Those activities will help enhance and enjoy the free time.
• Comfort-zone: It is OK to play for some time. Make sure it doesn’t take more than 33% of your time. Chat with your friends, check out the timeline, or anything that makes you refreshed.
• Normal-zone: Let the normal part be a part that challenges you and inspires you sometimes. Maybe reading articles, or a useful youtube channel, or anything that sometimes will be useful, and sometimes not.

---

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/

开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《开源指北》
今日推荐英文原文：《The Do’s and Don’ts of Code Reviews》

---

今日推荐开源项目：《开源指北》传送门：项目链接
推荐理由：开源指北是10月启动的一个项目，是一个开源新手教程，旨在为那些想参与开源的开发者们提供一个丰富详实的操作指南，让更多开发者认识开源、参与开源、爱上开源。目前已经完成了电子书修订活动，在 Gitee 项目页面即可阅读。

---

今日推荐英文原文：《The Do’s and Don’ts of Code Reviews》作者：Mike Pesate
原文链接：https://medium.com/better-programming/the-dos-and-don-ts-of-code-reviews-77032ba3a30c
推荐理由：给代码阅读者和代码作者的一些建议。

The Do’s and Don’ts of Code Reviews

Reduce team friction by having healthier code review cultures

Code reviews are an essential part of the development process. They help to maintain code integrity, quality, styling, prevent bugs, and even help us learn from others. The big barrier with code reviews is that they are usually done in an impersonal matter — such as leaving comments on a platform like GitHub, Bitbucket, or whatever version control you use on your team.

Since code reviews are done via text — the way we write, the words we choose, the mood we have when reading or writing or anything really can easily create friction with our teammates. To avoid this, we have to be mindful of how we approach code reviews. As such, I’ve compiled a list of Do’s and Don’ts to follow during code reviews.

As a Reviewer

Here’s a list of behaviors to do and void when reviewing other people’s code.

Do’s

• First of all, be polite.
• Be humble, and offer your help.
• If it’s not wrong and the solution is based on preference and opinion, then let it be — unless your team has a specific styling rule on how to solve certain problems.
• Ask for clarification when you have doubts.
• Highlight the good parts of the code as well, not only the mistakes. People deserve to be praised for their work.
• Approach the owner directly if you need clarification on a huge question. Code reviews are mostly async and written. A quick call can help settle doubts quickly.
• Have a checklist of things to look for. This will help speed up and streamline the review process (i.e., check styling, agreements, naming convention, does the code have tests, and more). You can even use tools like a linter to help you cut down on some of the review efforts.
• Write the comments as you want others to write them to you.
• Make time to review the code. Your teammates work depends on you to be complete. Give it the importance it deserves.

Don’ts

• Avoid using words like always or never.
• It might be obvious but, don’t insult people.
• Don’t use hyperbole.
• Avoid jokes and sarcasm. The written word is easily misinterpreted.
• Don’t assume things.
• Avoid blaming people.
• Don’t leave comments like “change this,” “this is wrong,” “find another solution,” etc. Be constructive, offer your help, and give suggestions.

As the Author

As the owner of the code, there are certain things you can do to make the review process easier on your team members.

Do’s

• Be polite.
• Thank people for their help.
• Ask questions on comments you don’t fully understand.
• If someone proposed a solution that you disagree with or don’t understand, try to set a meeting with that person and talk it out.
• Leave clarifications on the sections of code that might be too complex to understand when reading it without having all the context visible. Some solutions span across multiple objects and a code review might not present them in a way that is easy to make the connection.
• Have good and meaningful commit messages.
• Changes you do after opening the code review should have their own commit. This helps reviewers know what changed based on feedback.
• Try to answer as many comments as possible and gives thanks when necessary. Acknowledging someone’s comment doesn’t mean you agree, it just means you read it and appreciate the feedback.

Don’ts

• Try to not take comments personally. They are reviewing your code not you as a person.
• Same as when reviewing, don’t insult people.
• Don’t assume. (See image above)
• If a comment seems like an insult or attack, step back and read it again. You might be misinterpreting it. Write to the commenter directly if you feel like clarification is needed.
• Avoid jokes and sarcasm.
• Don’t shift blame by saying things like “I copied this from this file.” or, “This person made it the same way.” Sometimes, mistakes fall through the cracks, but this shouldn’t be taken as a precedent to keep doing them. Always strive to write better code.

Conclusion

There are more things that you could be doing to improve the way you give and receive reviews, but with this list, you should be on your way to a better approach.

One thing you can do is discuss this post with that colleague that might check all the ticks on the don’ts list. Help them be better by being better yourself. People can’t improve by photosynthesis.

---

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/

开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《955.WLB》
今日推荐英文原文：《Firefox 85 hammers the final nail into the Adobe Flash coffin》

---

今日推荐开源项目：《955.WLB》传送门：项目链接
推荐理由：955 不加班的公司名单 – 工作 955，work–life balance (工作与生活的平衡).与 996.ICU 相呼应，955 公司白名单。旨在让更多的人逃离 996，加入 955 的行列。

---

今日推荐英文原文：《Firefox 85 hammers the final nail into the Adobe Flash coffin》作者：Stephen Shankland
原文链接：https://www.cnet.com/news/firefox-85-hammers-final-nail-into-adobe-flash-coffin/
推荐理由：随着 Mozilla 于周二发布 Firefox 85，Adobe 曾经无处不在的 Flash 技术真的绝迹了。 尽管 Adobe 于 2020 年底停止了对该软件的支持，但该软件已被广泛用于在网络上扩展游戏，视频和动画。而Firefox, 最后一个支持 Flash 的主流浏览器, 也停止了对flash的支持.

Firefox 85 hammers the final nail into the Adobe Flash coffin

With Mozilla’s release of Firefox 85 on Tuesday, Adobe’s once ubiquitous Flash technology is really gone for good. The software had been widely used to expand gaming, video and animation on the web though Adobe stopped supporting it at the end of 2020. Firefox was the last major browser to support Flash.

Apple, whose former late boss Steve Jobs helped sink Flash by banning it from iPhones and iPads, ditched Flash with Safari 14 in September 2020. Google Chrome, the most widely used browser, completely excised it on Jan. 19 with version 88. Microsoft’s Edge 88 followed suit on Jan. 21.

The schedule of removals shows just how hard it is to advance technology foundations as widely used as the web. Browser makers for years wanted to remove Flash, replacing it with more advanced standards built directly into the web. Jobs’ “Thoughts on Flash” letter in 2010 solidified the opposition, and Adobe started recognizing the software’s doom by scrapping the Android version of Flash in 2011.

It’s taken years of effort to drop Flash completely. Adobe took until 2017 to announce that Flash would be completely unsupported at the end of 2020, and still some are willing to jump through lots of hoops to keep Flash around a little longer.

Software company Macromedia developed the Flash Player browser plugin in the 1990s and tools to help developers create Flash content. Flash eased the difficulties of video and audio on the web, paving the way for sites like YouTube.

Flash also powered countless online games and improved graphics and animation, expanding what developers could do during a time when development of web standards had largely stalled. Its browser plug-in design meant the same software worked on lots of browsers, including Microsoft’s dominant but lagging Internet Explorer.

But Flash’s success was overshadowed by its problems, notably security risks and power consumption. When Apple booted Flash from iPhones and then iPads, it undermined a key Flash promise: the ability for developers to write “cross-platform” software that ran on a variety of computing devices.

Now, Flash is no more, and browser blog posts and release notes make the finality of the decision clear.

“There is no setting available to re-enable Flash support,” Mozilla said.

---

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/

开源日报 每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《公务员 coder2gwy》
今日推荐英文原文：《Stop Using Magic Numbers and Variables in Your Code》

---

今日推荐开源项目：《公务员 coder2gwy》传送门：项目链接
推荐理由：这个项目是作者结合亲身经历写的程序员考公指南，不管是因为工作方式还是环境等等各种原因，想要离开这一行另寻出路的话，考公务员也并非不可能，尽管需要大量时间准备，过程也相对繁琐，不过读完之后想到作者上岸成功之后的种种好处……

---

今日推荐英文原文：《Stop Using Magic Numbers and Variables in Your Code》作者：Martin Andersson Aaberge
原文链接：https://medium.com/better-programming/stop-using-magic-numbers-and-variables-in-your-code-4e86f008b84c
推荐理由：尽可能使用对所有人而不是只是现在的自己有意义的写法

Stop Using Magic Numbers and Variables in Your Code

No one will understand your program. Not even you

Have you ever scratched your head reading code you didn’t write yourself? Of course you have. You’re not a bad programmer who can’t read code. Maybe the programmer who wrote the code was a magician — the wrong kind of magician. Keep this quote in the back of your head while coding.

“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” — John Wood

Many programs suffer from the fact that they aren’t written with another reader in mind. If you don’t have the violent psychopath in the back of your head while writing code, chances are some bad code will sneak in. You might have a hard time reading your own code as well after a while unless you write code that everyone will understand forever.

What Is Magic?

Please don’t confuse the magic we are talking about today with magic methods (Dunder methods). You have most likely used init as an initializer for your class. Have you tried using str to control what happens when you print your object? The magic we don’t like is magic variables and magic numbers.

Magic variables

A magic variable has a variable name that does not reflect what it represents. The name is complete gibberish, and it isn’t meaningful to the reader. The following code declares a magic variable:

a = [i for i in range(1,7)]

a can be anything. Sure, it’s a list ranging from 1–6, but how will we use it? Grades, doors in the room, leftovers in the fridge? There is no way you can know what this code is supposed to do.

dice_alternatives = [die for die in range(1,7)]

The code was all about dice, and the code created a list based on the number of faces the die had. Now it makes sense. Can you see a way to improve the code above? It is limited to a standard die. Because we are used to the dice with six faces, we are OK with this code. However, in the world of dice, you have a range of options.

die_faces = 6
dice_alternatives = [die for die in range(1,(die_faces+1))] 
//+1 cause range does not include the last number.

I bet you have seen a matrix created like this:

for i in range(3):
    for j in range(3):
        print('*', end='')
    print()

A tiny adjustment turning i into row and j into column can go a long way.

Magic numbers

Consider the following code:

x = 13
y = 21
if x>=y:
    print('old enough to drink')

The code can make sense because you understand it is about the drinking age. The code does not read well because x should have been age and y should have been legal_age. It could look something like this:

age = int(input('What is your age? (whole number)'))
legal_age = 21
can_drink = Falseif age>=legal_age:
    print('old enough to drink')
    can_drink = True

As I said, this is not the worst offender of magic numbers. It becomes harder to understand if you use a number in the middle of an expression.

distance = orig_distance * 0.393701

Only a trained eye will catch the conversion to inches. Especially if this only relates to a small part of the code, where the rest uses metric numbers. Without any comments or a proper variable name, this will be hard to understand for many programmers.

There’s a library for that

In some cases, you can use libraries. We all know that pi is roughly 3.14. Because we talk about pi as 3.14 in our daily speech, it is tempting to use this value in our code.

circle_radius = 12.6
area_circle = 3.14*circle_radius**2
print(str(area_circle))

The code above returns 498.5064. The code and result look fine because we can assume that everyone knows that pi is 3.14, but it might not be good enough in your case. There is no confusion about what we are trying to say with our code using the math library, and it is more accurate.

import mathcircle_radius = 12.6
area_circle = math.pi*circle_radius**2
print(str(area_circle))

The code above returns 498.7592496839155.

Why Are We Implementing Bad Coding Habits?

In all honesty, it’s not all your fault. How many times have you seen courses where you do nested loops with j and k, loops with i, the parameter n in functions, and variable names like a, b or c? This does not happen on YouTube only. It happens all the time at universities and other locations where you learn programming. Most coding tutorials I have watched will, at some point, use magic variables and magic numbers in lessons. The main reason for this is that you don’t want to waste time watching someone make up good variable names. A real-time explanation is more forgiving. A poor variable name doesn’t hurt the teaching at that moment. However, code is often supplied as extra material, making it harder to understand on its own later. When you want to show someone a quick example, it is easy to make variable names that are meaningless and impossible to read later. After a while, you start to slip these into your real code, and you have begun implementing your bad habits into your daily work. A big red flag should be waving at that point.

Final Thoughts

Let’s make a deal. It’s OK to use poor variable names when you discuss a snippet of code with your peers. It’s OK to do this when you test your code. Hopefully, you will have time to refactor it later. (We know you never have time to refactor. Let’s not fool ourselves.) When you write code others will use or code you will go back to in a year to maintain, please keep the magic out of it. Of course, if your code is magical, that’s great. If it is full of magic variables, it’s not. Let’s kill the wrong kind of magic and keep the right one in our code moving forward. Thanks.

---

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/