开源日报 - Page 66 of 262 - Open Source Daily

开源日报第778期：《背景消失魔术 Background-Matting》

20 5 月, 2020
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《背景消失魔术 Background-Matting》
今日推荐英文原文：《Find and Fix Bugs Like a Pro With Divide and Conquer》

今日推荐开源项目：《背景消失魔术 Background-Matting》传送门：GitHub链接
推荐理由：科学发展到一定程度就会变成魔术这句话可不是吹的。这个项目能够将背景去除做到更高层面——不再需要那个突兀的绿色背景板，即使是对于正常的背景环境，它也能识别并清除，让主体基本没有违和感的保留下来。唯一的缺点估计就是，随着它的发展，造假的视频也会获得更好的技术吧。
今日推荐英文原文：《Find and Fix Bugs Like a Pro With Divide and Conquer》作者：Szymon Adamiak
原文链接：https://medium.com/better-programming/find-and-fix-bugs-like-a-pro-with-divide-and-conquer-d55f3cf91154
推荐理由：我相信不少人在刚学习调试代码的时候都喜欢把代码一分为二
Find and Fix Bugs Like a Pro With Divide and Conquer

If I could learn only one thing about debugging, I’d learn to divide and conquer

Divide and Conquer
Divide and conquer is an algorithm design type. It works by recursively breaking a problem in two (or more) smaller problems of a similar nature. If you can solve the little issue, you can solve a bigger one too. Divide and conquer is used primarily for sorting or finding the closest pair of points.

But divide and conquer is more than that. It’s a mindset you can use to debug your apps.
Debugging
Debugging is a tiring task for many developers. You need to know your intended inputs and outputs. You need to understand the code and the flow of the app. Often finding a mistake is much harder than fixing it.

Countless programmers hate debugging for another reason. We prefer making things than fixing them. It’s a lot more satisfying to create new code than to spend half a day seeking an error and finally changing two lines.

The naive approach to finding bugs is going through the code line by line, logging data, or setting breakpoints. You can use that in trivial apps or if you know almost exactly where the mistake is.

But typically, you need to debug a big application, frequently before you can familiarize yourself with the codebase. Making tons of logs will take forever. You have to do better than that.
Basic Divide and Conquer
The straightforward use of divide and conquer in debugging is to split the codebase in half, and add a log there. If the log works and prints correct data, we can assume that everything up to that point works fine; if not, the error is in the first half of the code.

Next, we take the suspicious half of the code and put another log in the middle. We repeat the procedure until we discover the issue. Each time we cut the remaining codebase in half, so we should find the error in just a few steps. That’s a lot better than logs all over the code, but we can go a step further.
Educated Guesses and Divide and Conquer
Imagine your app consists of thousands of lines. It’s hard to find the middle, and you’ll need dozens of logs to discover the culprit. Now it’s the time to take a step back and think before adding logs.

Start with answering a few questions and making some hypotheses.

What broke? Is it likely that some string transformation failed; maybe data returned is not in the type you expected, or is there another issue?
- Do you have some tests or checked parts of the code? If so, the bug probably isn’t there.
- When did the bug occur? Did everything work fine before? What changed? Maybe inputs are different now, or maybe the code worked two commits back.
When you answer these questions, you’re ready to make an educated guess about the nature of the bug.

Every assumption can prove wrong, but your goal isn’t to be correct. It’s to find the most probable culprit so you can pinpoint the suspicious parts of code.

When you have a few hypotheses, zoom in on the most likely and use divide and conquer. If you find the bug, that’s great. If not, proceed to the next hypothesis.
Divide-and-Conquer Example
I’ll show you a real-life example of divide-and-conquer debugging. The code below takes an HTML form and creates a PNG image of it. Later, it sends both the image and the form data to the server and redirects to another page.

Specifically:
- toPng takes the HTML element and returns an image (base64-encoded data)
- dataUrltoFile takes base64-encoded data and returns a file
- saveFormScreenshot and saveDraft send data to the server
- setRedirect redirects to another page
The code worked well in Chrome, but I had a problem with Safari. The program didn’t return anything — no data, no error.
My (naive) approach
I’ve logged a response right before the middle of the code, between lines 4 and 5. The log never ran, so the issue was above.

My next step was to log formAsFile between lines 2 and 3. That log didn’t run either.

Now I got my answer — the bug is hidden in the first line. The function toPng never finished.
Educated-guess approach
In the first place, I should have analyzed why I didn’t get an error. I should have gotten one if there were issues with the request to the server. So the most probable place of failure was in lines 1 or 2. A simple log in the second line would suffice to tell me I never got the image out of the HTML.
Conclusion
Divide and conquer is a handy approach to finding bugs. You need it in your toolkit.

And if you’re wondering what the underlying bug was — the HTML element was too big for Safari to convert to the image.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第777期：《Coursera-ML-AndrewNg-Notes》

19 5 月, 2020

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《Coursera-ML-AndrewNg-Notes》
今日推荐英文原文：《The most successful developers share more than they take》

今日推荐开源项目：《Coursera-ML-AndrewNg-Notes》传送门：GitHub链接
推荐理由：在本课中，您将学习最有效的机器学习技术，并获得实践，让它们为自己的工作。更重要的是，你会不仅得到理论基础的学习，而且获得那些需要快速和强大的应用技术解决问题的实用技术。最后，你会学到一些硅谷利用机器学习和人工智能的最佳实践创新。
今日推荐英文原文：《The most successful developers share more than they take》作者：Ben James
原文链接：https://stackoverflow.blog/2020/05/14/the-most-successful-developers-share-more-than-they-take/
推荐理由：技术大牛开发者经常向别人无私地分享自己的技术知识。乐于分享自己的知识是很多顶级开发者成为大牛的原因,而非结果.
The most successful developers share more than they take
Ever since I started programming and discovered the open source world, I confess I’ve been a little obsessed with the elite developers in our communities. People who lead large open source projects (and often many of them) or direct large teams commercially. What is about them that got them to where they are? The software community has an abundance of advice and support on how to become a better developer, how to progress your career, and develop personally; I like to think programmers are pretty good at self-introspection and closing their own feedback loops. So amid a sea of extremely qualified professionals, what does it take to lead and create successfully?

To answer this question, and because I have a general curiosity around the topic, I set up a podcast, Distinguished Devs. Talking to top developers has been fascinating, and I’ve learned more than I thought was possible when I started the podcast. So I’d like to share some of that knowledge in this article.

What’s the common factor?

After interviewing several developers, a pattern started to become clear: great developers share a lot. This takes different forms for different people, but is very often a blog. “So what?” you might say, you would expect successful people—“thought leaders”—to use their position and platform to share their own ideas and projects. But the interesting thing is that for many top developers, their sharing mindset came before their success, and was the direct cause of it, not the result of it.

Take Jeff Atwood, for example. Jeff co-founded Stack Overflow and Stack Exchange and went on to later found Discourse. The reason this all started is entirely due to his blog, Coding Horror.

On my podcast, Jeff tells the story of how one day he checked the stats on his blog and realized he had 40,000 subscribers. He’d been sharing his thoughts on software and a little bit of everything else since 2004, and he realized he wanted to do something with the energy and following that he had. After reaching out to Joel Spolsky (who also happened to have a very successful blog, joelonsoftware), they started Stack Overflow.

Without the critical mass of users from their blogs to kickstart Stack Overflow, its fate might have been very different. But more than that—the idea would never have been realized at all if either of them hadn’t blogged.

For yourself, not the audience

One of the questions I always ask successful bloggers is: what motivated you to start? The answer is always the same: I did it for myself.

This is an example of survivor bias; those who start a blog with the aim of attracting a following will lose motivation and grow impatient with the short term results. Successful bloggers have the personal confidence and passion for the topic to document and share stuff they think is cool.

Miguel Grinberg, the author of the Flask Mega Tutorial (regarded by many as the top Flask resource) talks on my podcast about how the first installment received a single like and retweet on Twitter. Months of writing new installments brought little more engagement, it took years for it to gain traction. But it didn’t matter to him, because “I was having fun, following my interests, doing it for myself.”

Martijn Pieters, the world’s top contributor to Python on Stackoverflow, discussed on my podcast his motivation for answering the volume of questions with the quality he does. For him, it’s about curiosity and expertise. Quoting Eric Lippert (a core engineer of the Microsoft C# compiler, and also a blogger), he says “How do you become an expert on something? Well, find a pile of questions or a place where people are asking questions about your topic. If you try and answer each one, you’ll become an expert quickly enough.” That’s not to say there’s no reward or motivation in answering questions to help others, just that the personal benefits of doing so often go underestimated.

The same is true for many successful open source projects, which often start out as personal projects, only to later be adapted for general use. When I interviewed John Leider, the creator of Vuetify, about how the project started, he initially built it just for himself to enable rapid prototyping of sites for his consulting business. “I actually never planned to release it, it was going to be a thing for me. One of my buddies at work was walking by one day and said, that looks really cool. After a bit of talking, he convinced me to release it as an open source project.”

From the outside, the idea of doing something for yourself, not the audience looks like the main benefits of sharing come from the network of people you attract, and the opportunities created by a raised profile, such as new jobs, consulting, project offers and speaking opportunities. While this is true, top software engineers have told me that this long-term benefit was never their goal—the act of sharing creates significant short-term personal benefit.

Public by default

Though it’s important to create things for yourself, this shouldn’t mean you keep them to yourself. Carsten Haitzler (AKA Rasterman), the creator of the Enlightenment window manager, started the project only for himself, simply because he wanted a prettier desktop environment. On a whim, he shared some of the screenshots online, and all of a sudden began receiving emails from people asking for the source code. Fast forward to today, and the Enlightenment libraries are used in millions of phones, desktops, and even Samsung smartwatches and smart TVs.

The key point is that whilst the motivation for any successful project has to come from within yourself, you shouldn’t stop yourself sharing it because it was never meant for an audience. This idea surfaces frequently when I’m talking to podcast guests, because it’s always surprising how people react. Whatever your work, you should embrace the philosophy of “public by default”.

Public-by-default means this: everytime you create something, learn something, or just notice something’s interesting, do it in public. This may seem daunting—writing blog posts, helping the community and transforming ideas from thoughts into words all takes time. But sharing is like a muscle, and by committing to a regular schedule, you become much more efficient. This consistency of volume is also key to reaping the benefits of sharing. There are a number of reasons why the public-by-default principle accelerates your personal development so rapidly. Firstly, on a technical level, there’s an immediate feedback loop. If you’re answering questions on forums or online communities, considering strategy or contributing to open source, you have such a swift feedback loop that it’s impossible not to improve.

What’s more, the hive-mind of the internet has a habit of taking ideas you might have which are ok and turning them into something worth pursuing, adding value through different angles or directions. Blogs in particular are excellent idea generation platforms. I’ve had personal experience with this—as a freelance writer, some of my best leads for new pieces and learning opportunities come from comments people have left on my posts. To truly embrace public-by-default, it’s not enough to share your successful projects and knowledge, but additionally to bring the humility to share your learning and failures. In general, it’s hard to argue with the sentiment that you think harder about everything you do if you’re going to share instead of just do it for yourself, no matter how trivial it might be. There’s a lot of value to be had from being public-by-default, and often in ways which we don’t expect.

Sharing makes you stronger

For top software developers, sharing isn’t a byproduct of their success—it’s often the cause of it. The reasons for this are many and varied, but having the confidence to share more, for yourself, can be extremely rewarding.

So the next time you make a weekend project, learn something or discover anything you think is cool, be sure to share it; you’ll be in good company.

The Distinguished Devs podcast is available on iTunes, Spotify, and other podcasting platforms.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第776期：《免费学习社区 freeCodeCamp》

18 5 月, 2020

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《免费学习社区 freeCodeCamp》
今日推荐英文原文：《Tabs vs. Spaces》

今日推荐开源项目：《免费学习社区 freeCodeCamp》传送门：GitHub链接
推荐理由：freecodecamp.org是一个免费学习编程的社区网站，课程完全免费并且自主安排。网站有数以千计的交互式编码练习，以帮助您扩展您的技能。
今日推荐英文原文：《Tabs vs. Spaces》作者：Kenneth Reilly
原文链接：https://medium.com/@kennethreilly/tabs-vs-spaces-3c24defa7c9e
推荐理由：关于是使用Tab键还是使用空格键缩进的争论在编程界已经持续了多年，不过Tabs可能是更好的选择，是因为空格需要多按几下吗？
Tabs vs. Spaces

A scientific approach to an endless debate

Introduction
The debate over whether to use a tab or a space for indention has been long-running for many years in the programming community.

I use tabs for indentation myself, originally because that was what our senior developers used at my first software job, and to this very day for various reasons, most of which are logical and mathematical in nature. In this article, I will outline these reasons and shed light on this topic.

Code Indentation
We indent source code to make it more readable for humans, and for no other reason. This is fundamentally no different than indenting a list on a page in an old-school textbook or other document, for which the tab key was developed and included in every major typewriter design in history.

The spacebar key, on the other hand, was not developed for the purpose of indenting content on a page, but for separating words in a sentence. So, when we inspect the tab versus the space when it comes to typing content in a readable fashion, the tab wins by virtue of having been designed for the specific purpose of indenting text in order to make it more readable.

So now that we have examined the true purpose behind each character and reached the conclusion that the tab exists for the sole purpose of indenting content while the space does not, let’s examine the efficiency of using each.

Efficiency
There is an unspoken concept among many senior developers who grew up in the 80’s and 90’s with limited tech resources, that many programmers today have a bad habit of taking for granted the kind of power and bandwidth that are available to the modern software developer. While it’s a good thing that we have the kind of resources we have today on modern client, server, and networking machines, it’s still a bad habit to assume that raw power will make up for a lack of efficiency on the part of the developer.

While the machine doesn’t actually care if you use tabs or spaces (unless you’re using Python or something similar in which whitespace is part of the syntax), the size of your source code will increase by the use of spaces over tabs, especially if you indent by four spaces. If you are five levels deep in a nested function and you’re indenting an expression like String str = '' with 20 spaces, that line of source code contains more indentation characters than it does code, which is truly absurd by any standard. Multiply that by hundreds (or thousands) of files, with hundreds of lines of code each, and you’re going to have MBs upon MBs of spaces everywhere.

Conclusion
So, at the end of the day, tabs versus spaces is truly a matter of preference, however the tab is still the character specifically designed for indentation, and using one tab character per indentation level instead of 2 or 4 spaces will use less disk space / memory / compiler resources and the like. It’s also arguable that full tab indentation produces more readable code, and will encourage a developer to utilize proper abstraction, encapsulation, and other practices, since not doing so will result in highly nested logic with indentation going off the screen (something that isn’t as much of an issue when indenting with two spaces).

How you see your code every day has a huge impact on the kind of success you will have long-term as a developer, and clean logic is much easier to read and requires fewer mental resources (meaning more can be put into the actual work you’re doing instead of in maintaining hard-to-read code).

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第775期：《密码学教程 sha256-animation》

17 5 月, 2020

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《密码学教程 sha256-animation》
今日推荐英文原文：《I Don’t Want to Go Back to the Office》

今日推荐开源项目：《密码学教程 sha256-animation》传送门：GitHub链接
推荐理由：sha256，密码学里的玩意。这种算法的步骤多如牛毛，会把人绕的晕头转向，这个项目将它的过程用动画展现在命令行中——光是用动画展现出来都能占满一屏又一屏的命令行窗口，不过项目内对每个部分的算法操作都做了解释说明，复杂的步骤一份份拆开之后还是能够理解的。
今日推荐英文原文：《I Don’t Want to Go Back to the Office》作者：Roberto Hernandez
原文链接：https://medium.com/better-programming/i-dont-want-to-go-back-to-the-office-a0dd580cf07
推荐理由：家里上班也太棒了吧
I Don’t Want to Go Back to the Office
After reading that major companies such as Google, Facebook, Amazon, Slack, and Twitter were seriously thinking about allowing their employees to work from home for the rest of the year, I began to believe that my current company will do the same.

I hate the idea of returning to the office. The idea itself makes me feel sad. This sort of thought doesn’t mean I don’t want to see, talk, or ask random stuff to my closest coworker at the office at all.

Certainly, I miss doing a few things I used to do, like talking a little bit while we were queuing to get a cup of coffee at the coffee machine or playing ping-pong. However, deep down, there are more powerful reasons why I don’t want to return to the office. We will discuss them throughout this article.
Our New Lunchtime
On certain days, I would sit with my wife during our new lunchtime together. I would slowly look at her and say, “I don’t want to return to the office. I hate the idea of returning to the office. I want to work from home from now on — just without any lockdown.”

She turned her eyes on me and told me, “That would be the best thing for us.”

Returning to the office would mean losing many meaningful things that have become an essential part of my day-to-day. Furthermore, I would lose the chance to build some things while staying at home that I couldn’t build at the office.
I Won’t Build a Comfortable Home Space
At some point when you work from home, you will feel the need to build a comfortable workspace. I am talking about a really proper and comfortable space where you find inspiration and creativity.

If I come back to the office, I’m not sure if that will be tagged as a priority. Honestly, I would probably lose the will to build it.
I Won’t Hug My Son at Random Times During the Day
From the beginning of the lockdown until now, I have been blessed with the opportunity to hug my son at random times during the day — whenever I go to the bathroom, prepare a cup of coffee, or take a breather out on the courtyard. That is really amazing and refills my tank in a certain way.

I’m able to see him awake after his naps. I also have the chance to hear his sweet voice or anything funny he might say when he is a little far from me.

So if I come back to the office, I will only have the chance to appreciate that and feel the same way once or twice a week since we live in different areas.
I Won’t Have the Freedom to Take a Shower at Any Time
There are some days when the weather is terribly hot. Moreover, there are certain stressful things you face on a daily basis. These conditions make me feel stuck most of the time — and it turns out a shower is a perfect cure. To throw away this feeling, I usually take a shower, and my flow and energy start to come back.

While you are working from home, you have the freedom to take as many showers as you like at any time of the day. There are many benefits to taking several showers during the day. It helps to reduce stress and gives you a higher level of alertness.
I Won’t Receive a Freshly Made Tortilla From My Closest Neighbor
Due to the pandemic, I’m not living in the city. I moved to the place where I was born and grew up.

My closest neighbor sometimes comes up near a window of my house to ask me if I want a freshly made tortilla, a slice of pizza, bread, or anything else she has cooked. That is amazing! I relish all that comes from her.

If I come back to the office, I will obviously miss this kind of gift.
I Won’t Save Money, and I Have To
Undoubtedly, when we work from home, we have a large list of benefits. From my point of view, there are two of them that are fundamental: saving time and money.

All of us want to save money and earn more, right? So working from home allows us to save money since we’re not using cars or the public transportation system. Our money is not running out as fast. On the contrary, we are saving more.

Also, you do the grocery shopping more wisely and often cook your own food. Without buying food or going out as often, you’re saving even more money.

And since this pandemic has caused economic chaos, it’s a good idea to spend less money than before. We have to save money as much as we can to avoid future headaches and disappointments.
Closing Thoughts
I just wanted to share some powerful reasons why I hope not to return to the office. Furthermore, our world will never be the same after this pandemic. Working from home will not be the new way of working but simply the normal way. It already feels like it!

Thanks for reading! I really appreciate it.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/

开源日报第778期：《背景消失魔术 Background-Matting》

Find and Fix Bugs Like a Pro With Divide and Conquer

If I could learn only one thing about debugging, I’d learn to divide and conquer

Divide and Conquer

Debugging

Basic Divide and Conquer

Educated Guesses and Divide and Conquer

Divide-and-Conquer Example

My (naive) approach

Educated-guess approach

Conclusion

开源日报第777期：《Coursera-ML-AndrewNg-Notes》

The most successful developers share more than they take

What’s the common factor?

For yourself, not the audience

Public by default

Sharing makes you stronger

开源日报第776期：《免费学习社区 freeCodeCamp》

Tabs vs. Spaces

A scientific approach to an endless debate

Introduction

Code Indentation

Efficiency

Conclusion

开源日报第775期：《密码学教程 sha256-animation》

I Don’t Want to Go Back to the Office

Our New Lunchtime

I Won’t Build a Comfortable Home Space

I Won’t Hug My Son at Random Times During the Day

I Won’t Have the Freedom to Take a Shower at Any Time

I Won’t Receive a Freshly Made Tortilla From My Closest Neighbor

I Won’t Save Money, and I Have To

Closing Thoughts