开源日报 - Page 164 of 262

开源日报第388期：《来点音乐 Tone.js》

7 4 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《来点音乐 Tone.js》
今日推荐英文原文：《Why you should choose mindfulness over multitasking》

今日推荐开源项目：《来点音乐 Tone.js》传送门：GitHub链接
推荐理由：这个项目可以让你在浏览器中创建交互式的音乐，即随着用户的操作播放的音乐。如果对音乐的创作有过一定了解的话，这个 JS 库肯定能够让你大显身手。它的网站上提供了相当多的 demo，即使是没有学过音乐的人也可以作为参观去玩一下它们。
今日推荐英文原文：《Why you should choose mindfulness over multitasking》作者： Sarah Wall
原文链接：https://opensource.com/article/19/4/mindfulness-over-multitasking
推荐理由：在专注和一心多用两个不同方式，作者认为前者更值得采用
Why you should choose mindfulness over multitasking
You have your morning coffee in hand, you’ve just finished your daily scrum, and you sit down at your computer to start your day. Up pops a Slack message. You scan your emails, then bounce back to Slack. You look at your calendar to see when your next meeting is—much to your surprise, it’s starting in 15 minutes. You get back to your desk and check your to-do list to see what tasks you can fit in before your next meeting, but one of your co-workers asks for your help to solve a problem. Before you know it, half of your day has disappeared.

Many of my days are spent like this, juggling multiple tasks. There are moments I find myself staring at my computer with my brain at a complete halt. If you, too, find yourself in this situation, it’s probably a sign from your brain to take a break. You could be suffering from too much multitasking and decision fatigue.

On average, adults make about 35,000 decisions every day! They can be simple decisions, such as what to eat or what to wear, or decisions that require more thought, such as where to go on your next vacation or which career to pursue. Every day you are faced with a plethora of choices to occupy your mind.
Mindless multitasking
Not only are you faced with making thousands of decisions each day, but multitasking has also become the norm for busy and in-demand professionals. The problem is, multitasking hurts more than it helps. The more you divide your attention through multitasking, the more your productivity decreases.

In a study, self-described multitaskers were asked to switch back and forth between tasks at a pace that felt natural to them. A control group was asked to do one job at a time in sequence. The multitasking group performed far less effectively. Each time they switched tasks, there was a slowdown because it took time to time recall the details and the steps they’d done so far. This wound up making everything take roughly 40% longer and led to lower levels of accuracy overall. People who focused on one task at a time spent less time overall and finished all the tasks.
Choose mindfulness
The mind functions optimally when it can focus on one activity at a time. Choosing mindfulness over multitasking will result in better feelings throughout your day and help you do better work.

“Mindfulness” can be defined as being conscious and aware. It really is about being present in the moment and focusing your attention on what’s at hand. There are many advantages to mindfulness in the workplace. The trick is creating boundaries and habits that allow you to give each task your full attention.

Take a proactive approach and create a prioritized plan of the items that must get done each day. This will allow you to make real progress on a few things that are important instead of being reactive. Every item that goes on your to-do list should be discrete, clear, and actionable. Focus on three to five tasks per day.
3 ways to take a break during your workday
Don’t forget to plan breaks throughout your day. The brain needs a few minutes of rest every hour to recuperate and to avoid burnout. Taking mini-breaks is good for your mental health and leads to increased productivity.

Here are three easy ways to incorporate breaks into your day:
1.Move your body
Take 10 minutes to get out of your chair and go for a short walk. If you’re pressed for time, stand up and stretch for two minutes. Changing the position of your body and focusing on the present moment will help relieve the mental tension that has built up in your mind.
2.Laugh more
Take a break to talk with your friends and colleagues at work. Laughter decreases stress hormones and triggers the release of endorphins, the body’s natural feel-good chemicals. A little laughter break helps relax your mind and is also good for your soul.
3.Breathe deeply
Reset your mind and body with a two-minute break to breathe deeply into your belly. Deep breathing calms your mind and body, improves oxygen flow, and gives you a natural energy boost.
1. Sit up tall with a straight spine, bring your awareness to your belly, and allow it to soften and relax.
2. Begin with a slow, deep inhalation for a count of three, filling your belly, then rib cage, then upper chest with oxygen.
3. Pause for a second, then exhale from your upper chest, rib cage then belly, drawing your belly in towards your spine at the end.
4. Pause again, then repeat.
Reset yourself
The next time you find yourself at a standstill or pressuring yourself to finish a task when your mind is not in the flow, try some of the tips above. It’s better to take a short break and allow yourself to reset rather than trying to power through. Your body and brain will thank you.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第387期：《粗鄙之语 thefuck》

6 4 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《粗鄙之语 thefuck》
今日推荐英文原文：《Master your email with these essential Gmail tips》

今日推荐开源项目：《粗鄙之语 thefuck》传送门：GitHub链接
推荐理由：想必各位都有过敲命令行敲错的时候吧。这个项目可以用于在命令行中自动纠正命令，只需要一句粗鄙之语，它就会对你输错的上一个命令按照一定的规则进行匹配——如果你愿意，也可以自己加入自己的规则，如果匹配成功，它就会生成正确的命令并执行它，这可比找到输错的地方修改快得多。
今日推荐英文原文：《Master your email with these essential Gmail tips》作者：Laura Mae Martin
原文链接：https://www.blog.google/products/gmail/master-your-email/
推荐理由：管理邮件的小提示
Master your email with these essential Gmail tips
Your email can feel like a never-ending to-do list. And in a world where technology makes you more connected to work than ever before, how do you set ground rules to keep your energy up, your focus sharp and your sanity intact? As a productivity expert at Google, I help Googlers use products like Gmail, Google Drive and Google Calendar to get more done during their busy days. Email in particular can be a source of stress, but it doesn’t have to be.

Gmail had its birthday earlier this week, and for 15 years, it’s been a helpful sidekick for billions of people around the globe. Part of my job is sharing Gmail-related tips with fellow Googlers—here are my top 10 email management tips for you:
1. Cut down on notifications: Don’t bother your brain with notifications for every new email—proactively check your email instead. On your phone, you can set up notifications for certain emails—say, the ones from your boss. This will help you identify important emails and disconnect when you want to.
2. Respond within 24 hours, even if it’s only to check in: You probably can’t get to all emails within 24 hours, but you can avoid getting another follow up email from a coworker. Giving a status update—“Hi, I got this email but not going to get to it until later this week!”—is a great way to set expectations and show them you’re on it.
3. Close out your email 1-2 times a day: Email is necessary to get your job done, but it’s also the ultimate distraction. Most people leave it open all day and check it every 30 minutes (if not more). Try closing your email tab when you have time to do deep work: the ability to focus without distraction on a demanding task.
4. Don’t click on an email more than twice: If you read an email then mark it as unread, you’ll have to read it again to remember what to do with it. Read it once to scan and tag your future action (for example, labeling it as “must respond,” or “to do this week,”) then one more time when you answer it.
5. Sorting, reading and answering emails should be separate activities: Most people bounce between sorting one email for later, reading one, answering one and repeating. We lose so much energy switching between these activities. Instead, tell yourself “right now I’m sorting everything.” Then when you’re done, read everything you need to read.
6. Keep emails that require clear action—otherwise archive or delete: When your inbox contains emails without clear action items, it gives your brain the false sense of having too much to do. Be ruthless about deleting, archiving, or snoozing emails that don’t require an immediate action from you in some way.
7. Skip some emails: Every email you see takes a tiny piece of your energy, so each item in your inbox should be something you need to look at. Gmail lets you create filters so that certain emails “skip your inbox” and won’t appear as new emails. For example, if you get a lot of email newsletters, set up a filter with “Has the words:unsubscribe”—now, those emails won’t distract you, but you can search for them later.
8. Don’t mix your read and unread emails: Combining read and unread emails in your inbox is a recipe for anxiety. New emails should come into one section and emails that you’ve already read and require an action should be in a different section. You can create a Multiple Inbox pane or “move” emails to different label that denotes a specific action (such as “To Do” or “Follow Up”).
9. To stay focused, keep new email out of sight. It can be hard to answer pressing emails when you’re constantly tempted to open the bright and shiny new emails that just came in. Open up a section like your “Snoozed emails” (emails that you’ve saved for later) or your “Starred emails” (your high-priority emails) so you can stay focused on those tasks, instead of getting distracted by new email.
10. To find what you need, just search: Email labels can help you stay organized, but think about how Google got its start … Search! Searching your email—instead of digging through labels—is actually a faster way to find the email you’re looking for. You can search by date, sender, subject (and more) and you can get even more specific with queries like “has:attachment” or “older_than:6m” (m=months).
For those of you new to using G Suite, there are loads of ways to stay productive in email. Learn more or try it out for yourself. Now go forth, and tackle that email.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第386期：《震动波纹（物理） awesome-power-mode》

5 4 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《震动波纹（物理） awesome-power-mode》
今日推荐英文原文：《Debugging — A Philosophical Approach》

今日推荐开源项目：《震动波纹（物理） awesome-power-mode》传送门：GitHub链接
推荐理由：一个能够让你在写东西感受力量的项目列表，powermode 会让你的输入变得极其有力，如同连续普通拳打在屏幕上一般。虽然这玩意除了力量之外并不能给你什么其他的提升，但是——爽就完事了。

今日推荐英文原文：《Debugging — A Philosophical Approach》作者：Bogdan Litescu
原文链接：https://medium.com/@bogdan.litescu/debugging-a-philosophical-approach-bf60d6626f6e
推荐理由：调试与哲学的关系
Debugging — A Philosophical Approach

A Definition
You might ask what does philosophy have to do with debugging. I feel that’s a good clarification to start with. In common knowledge, philosophy has become the act of talking about the nature of things in general and, in particular, about the existence and purpose of life. This is a part of philosophy that most people face at some point or another in life.

But there’s another big part of it which is the glue that transcends all sciences. It’s about principles, methodologies, reasoning and understanding. The great philosophers in human history were, at the same time, mathematicians, physicists, logicians, historians and so on. The highest education degree one can get is a PhD, which stands for Doctor of Philosophy. It basically means that someone has reached a level where he or she can extrapolate principles and methods to apply to ideas in order to produce new research.

I derived the philosophical approach to debugging from being a programmer for more than a decade and from exploring human psychology, mostly in relation to myself. I believe these are two fields where debugging is a vital part to success. Now that’s a big word. For the sake of precision, in this article I assume that success consists of understanding the nature of things as a means to implement systems that produce desired effects.

Another distinction I’d like to make from the start is related to diagnosis. In medical sciences, in aviation, in car industry among others, people have been investigating for a long time why something doesn’t work the way it should and have put systems in place to easily identify when a failure occurs. What differentiate these from computer programming or psychology is that these systems change at a much slower rate and have a finite number of interactions between components. Fully describing everything at a certain point and keeping it relevant in time is feasible.

In computer science and psychology, it’s much more important to learn methods and principles, as the facts will vary wildly from individual to individual and from group to group. Both create systems that change rapidly in time. What is true today, could easily be obsolete in a few weeks.

From this perspective, I call debugging the set of principles and methodologies we can use to understand a specific behavior or state of an individual or system and describe it. Only when the debugging activity is complete will solutions and corrections can be coherently considered and applied.
Unwanted Behaviors
What triggers the debugging process is unwanted behavior. We notice these all around and within us. Sometimes we have systems in place that tell us that an unwanted behavior has occurred. This was the case with one of our websites at some point. It was both programatically tested and observed through personal experiences that the performance of the website was really poor sometimes. After struggling to figure it out for a few months, my team called upon me to assist. Although there are quite a few years since I’m not coding anymore, the universal principles and methods of debugging that I’ve been using are still valid. I will come back to this example as I explain various principles and methods I use.
In Pursuit of the Truth
Before going any further, let’s talk about motivation. Debugging is about finding the truth. I’ve seen programmers randomly applying fixes until the behavior was corrected and stopping there. They failed to find the truth. There is a byproduct of the debugging process that just as important as identifying and describing the root cause. That is the process of constantly improving ourselves. If we don’t understand what the problem was and why our change fixed it, we haven’t learnt anything. We are likely to produce the same wrong behavior over and over again and fix it every time. That’s one way to keep ourselves busy.

I find behavior to be the number one source of truths. By reading code, literature or listening to what people say, one might get deceived. We all make affirmations about how we’d act in a given situation only to realize that we act completely different when we’re actually facing the respective situation. Though our behavior is a source of truths, it is not the truth. In order to find it, we must start debugging.
Hypotheses and Assumptions
Once a behavior has been found to be unwanted, people will start giving opinions as of why it occurs. This is a healthy discussion, but one thing to watch for is people expressing personal opinions as convictions, without verifiable arguments to sustain them. Now is the time to clarify either the opinion is in fact an hypothesis based on assumptions that haven’t been verified yet. That’s very easy to clarify. Just ask for arguments and what sustains them.

Going back to the example of the slow website, the general conviction in my team was that we needed to increase the number of CPUs on the server. When I asked why, they didn’t have any verifiable arguments. Increasing the CPUs might have solved the effects of the problem, at least for a while. But since our software is used by thousands of companies, I encouraged the team to find out what’s causing the behavior. Worst case scenario was that we would have found something that requires more CPU, and in that case it would still be useful to inform clients.
Causality
So now we had two opinions:
- The server had too few resources.
- There is a defect or a resource intensive feature in our software.
When I put the opinions in this fashion, it became clear to everyone that 1 is very likely to be a consequence of 2, and that we should spend our time to investigate the software first.

Establishing causality between various hypotheses eliminates wasting on investigating the effects and makes it much clearer to decide where the debugging process should start.
Observation Tools
Once the starting point has been decided, it’s time to get insights. Despite all society advances, the observation remains one of the most important instrument we can use to understand how things work. But in a complex system, observing everything is not feasible. Therefore, observation works like Google Maps. You first observe the big picture and then zoom in on area of interest for more specific observations.

Luckily, there’s a multitude of tools that we can use to make the observation process much faster and precise. When I started public speaking, I used to records videos of myself and then identify areas I could act on to improve. That’s an easy example. In real life, it’s a bit more difficult to put tools in place to observe our personal behavior. There are various gadgets that help to some extent. And there’s always a generic tool we can use, which is being conscious of one’s self. This is a skill that can be practiced through meditation and other techniques.
Validating Assumptions
Going back to the slow website tools, we deployed a generic tool on the live site that recorded everything that was happening. We found that there were around 3 million database queries happening daily. That’s quite a lot more that we expected. However, we now had a metric that could validate other assumptions later.

During the debugging process we will find things that are objectively true. It could be that we have a tool to accurately measure something directly related to the behavior. Or, on a psychological level, it could be an external evaluation like, for example, asking input from our life partners if our unwanted behavior changed in the past week.

We can then use these truths to validate assumptions. As we go deep in the debugging process, a lot of what ifs will arise. We can then modify variables and observe how they affect the truths.
Asking the Right Questions
Observations collect data. However, data itself is useless without understanding it. Another great principle that’s universally available is to question the data. There is a very popular framework called the 5 Whys. I find this works, but it’s not as easy as it sounds. Why were there 3 million database queries per day? Before we can answer this question we have to answer a lot more like what are those queries and how do we measure them?

On our slow website, looking at 3 million queries was not feasible. So we went in and deployed additional tools that counted how many times different queries have ran. We found that most of them were supposed to be cached in memory. Only now can we get to next why. So, why is the cache not working sometimes?

But, just to point out, this last question is based on the assumption that cache was the issue. This assumption is not validated yet. So, on the 5 Whys framework, sometimes one might work down a branch of Whys that are based on assumptions. If at some point, an assumption is invalidated, one has to go back one or more levels to previous Whys and find different assumptions.
Build Your Own Tools
As you get deep into debugging, you might find the need to create your own tools to accurately observe or measure a component of the behavior. These tools don’t have to be revolutionary. In fact, people usually build specific tools from generic methods. Like, for example, composing a questionnaire and ask your colleagues to fill it in. Or, noting down how many times a day you perform a habit that you want to get rid of.

In my slow website example, we built a simple tool that displayed everything stored in cache.
Reproducible Behavior
Never underestimate the power of chance. During the debugging process, it might be that an assumption simply doesn’t validate because a certain condition has not been met during the experiment.

Therefore, in our pursuit for truth, we have to identify all components that cause the behavior. Only when we can reproduce it exactly can we act repeatedly on it to advance our understanding. Otherwise, we’re left to chance to validate or invalidate assumptions. This leads to another important method that’s been universally available since the dawn of human kind, the experiment.

In our slow website example, what made it so difficult to track down was that it appeared to happen randomly. We didn’t knew an essential condition that triggered it. To make it even worse, it didn’t happen when we tried to reproduce on a clone of the website. Therefore, we decided to use the tool to generate reports continuously to catch the moments when it did happen. This increased our chances to observe the faulty behavior from the caching perspective.

There’s two facts we found when using the custom built tools:
1. There were some caches that had names we didn’t expect.
2. The cache indeed seemed to randomly clear itself.
These two facts confirmed the assumption that it was a caching problem. We then asked ourselves if the two are related. More specifically, we investigated either fact 2 is a direct consequence of fact 1.
Reducing Complexity
Once an unwanted behavior is reproducible, one can eliminate parts until the minimum number of components that still produce the problem is found. Reducing complexity removes noise which could hinder our investigation or slow down experiments. I remember a time when the tools for computer debugging were rudimentary. It was popular at that time for software engineers to remove parts of code until the issues didn’t reproduce anymore. Then, they knew that the problem had to be somewhere in the part that was last removed.

Going back to the slow website, fact 1 was more easily to address. So, we decided to act in that direction, as it would both fix a defect and answer the question either fact 2 was related. In the end, it was not.
Tracing Last Steps
The missing essential condition hides in something that happened before the behavior was observed through its effects. Perhaps the most popular example to give is about when forgetting where the car keys are. After finishing looking in all the places I’d expect them to be, I try to remember and even reproduce the last steps I took after entering the house earlier that day, only to remember that I was in a hurry to the bathroom. So, I find them on the sink.

In computer programming, the last steps are called Stack Trace. So we’ve built ourselves another little tool that would monitor the cache and collect the stack trace the exact moment it happen. Going back through the steps, we finally have found the root cause. That website actually hosted 3 websites. The other two were internal to us. Only when someone accessed the internal websites, the URL rewriter would wrongly look at the cache of the main website. Because it didn’t match what was expected, the URL rewriter would clear the cache for all 3 websites. This fully explained the randomness of the behavior, as the internal websites were used a few times a day.
Getting Unstuck
Some unwanted behaviors will pull your hair out trying to get to the bottom of it. At times, you might find yourself stuck with no other assumption to validate. Do not despair. What I found to work is to get someone to help and put everything on the table. Debugging also involves a great deal of brainstorming, building logical arguments and thinking creatively about approaching the behavior from other perspectives.

One thing I found to be mostly true is that it’s usually small things that cause behaviors difficult to debug. And it makes sense. If it was something big, it would have been much easier to make an assumption and validate it.

In this regard, there’s another piece of advice that can make wonders: sleep on it.
Validated Knowledge
Once you got to the bottom of the unwanted behavior you can move towards addressing it. That might be a major effort as well, but it’s beyond the scope of this article. What I’d like to emphasize here is the by product of the debugging process, which are new methods and tools you can use in the future to approach a similar situation. And it’s not something you’ve read about in a book, but something that you lived first hand. You went in pursue of the truth and found it. It creates emotions and confidence.

This kind of knowledge, being validated by own experience, rewrites connections in the brain. It develops our intuition and makes us better at debugging.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第385期：《爬虫教学 Python-crawler-tutorial-starts-from-zero》

4 4 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《爬虫教学 Python-crawler-tutorial-starts-from-zero》
今日推荐英文原文：《“Why” is Why Software Implementations Take So Long》

今日推荐开源项目：《爬虫教学 Python-crawler-tutorial-starts-from-zero》传送门：GitHub链接
推荐理由：说到 Python 相信大家都听说过 Python 爬虫这玩意了。这个项目就是一个 Python 的爬虫入门教学，从爬虫的预备知识——爬虫相关和网络相关到如何自己实现一个爬虫，对于有一些 Python 基础的朋友来说作为入门教学来说已经足够了。
今日推荐英文原文：《“Why” is Why Software Implementations Take So Long》作者：Thejus Chakravarthy
原文链接：https://medium.com/@thejus.c/why-is-why-software-implementations-take-so-long-ready-dcab6a503325
推荐理由：先想好为什么而不是做什么和怎么做，这能帮你节省不少走弯路的时间
“Why” is Why Software Implementations Take So Long
Every process starts with a why as in ‘why are we doing this?’

Then, you get to what as in ‘what do we do?’

Finally, you get to how as in ‘how do we do it?’

At work, most people encounter a process in reverse, from how to why.

For example: my first job was working for a bookstore with a membership program. They taught me how to suggest joining our membership program. What I was doing was suggesting a customer become a repeat customer. Why I was doing it was because repeat customers tend to spend more, over time, than single customers.

I was only trained on how. It was up to me to figure out the what or the why.

Simple, right? Let’s get a little more complicated.

I was asked to automate web sales in an ERP. Apparently, every order from the website had to be manually altered before it went to the warehouse. Before I started coding or configuring anything, I interviewed the staff. When I asked how they altered the orders, I got step by step directions: first that button, then that field and so on. When I asked what they were doing, they said that certain items were only in one of the two warehouses and there was no way to configure the system to do this automatically. So, when an order came in, a person had to look at all the items and figure out if the entire order could be completed in one warehouse or if they had to coordinate multiple shipments.

When I asked why, I got blank stares or shrugs. This was a decision made outside their control and outside their concern. It just was the way things were.

Photo by Nick Tiemeyer on Unsplash

I think it’s important to point out that this isn’t a problem, as far as the stability of the business goes. Several business have functioned for decades without ever explaining why, even to themselves. “We’ve always done it this way” or “That’s the way I was taught to do it” is almost expected in certain industries.

But this is a problem when trying to implement a software platform.

Software platforms automate or streamline a process at the what level. A faster invoicing, a simpler tax report, a centralized resource planner, that sort of thing. The how in these platforms gets defined by the UI/UX design. If you’re super duper lucky, the interface is intuitive and easy to use. What’s more likely is you are going to be working against the interface, not with it.

A software implementer has to find out the shortest path between system’s how and your business’ how. Over time, the best implementers can connect the dots in days, if not hours. They can show you how to enter your sales orders, how to pay your bills, how to configure the email responses, and so on.

To do this, they have to figure out what you want to do. This part is usually called ‘gathering requirements’ or something similar. Then they can match your what to their platform’s what.

For example, your requirements say that you issue an invoice for every sale. They show you how to issue an invoice and move on. But later, you ask how to issue two invoices for the same sale, one for the deposit and one for the final payment. Well, you didn’t specify that in the requirements and that’ll require additional configuration and different documentation and training and so on. So the process goes back to the requirement gathering stage or the requirements get added to a change order and the process continues.

This breakdown occurs because neither side of the implementation got down into the weeds of why a process exists in the first place. If we knew why, several whats and hows could be put into place. But having to learn all of those hows is time consuming for both the implementer and the implemented.

The solution is simple but not easy.

Spend the time to find the why and what for every part of the business before even considering a new platform. Then, when trying to work with the implementer, focus on the why and the what rather than the how.

This process looks at lot like writing documentation or SOPs or playbooks. Whatever your business wants to call it, it boils down to a clear path from the why all the way to the how of everything you do.

In the end, it doesn’t matter how you accomplish a task.

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