开源日报 - Page 172 of 262

2019年3月7日：开源日报第357期

7 3 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《熟练的力量 python_interview_question》
今日推荐英文原文：《Why CLAs aren’t good for open source》

今日推荐开源项目：《熟练的力量 python_interview_question》传送门：GitHub链接
推荐理由：关于 Python 的各种面试题合集。从基础的 Python 问题到企业的面试题都有，关于数据库，数据结构和 Web 方面这些经常用到的题目也正在补充当中。不管是作为自己用来自我检测的题库或者是为将来的面试积累经验都是一个不错的选择。
今日推荐英文原文：《Why CLAs aren’t good for open source》作者： Richard Fontana (Red Hat)
原文链接：https://opensource.com/article/19/2/cla-problems
推荐理由：CLA，即贡献者许可协议，有人认为它有益，也有人不这么想
Why CLAs aren’t good for open source
Few legal topics in open source are as controversial as contributor license agreements (CLAs). Unless you count the special historical case of the Fedora Project Contributor Agreement (which I’ve always seen as an un-CLA), or, like Karl Fogel, you classify the DCO as a type of CLA, today Red Hat makes no use of CLAs for the projects it maintains.

It wasn’t always so. Red Hat’s earliest projects followed the traditional practice I’ve called “inbound=outbound,” in which contributions to a project are simply provided under the project’s open source license with no execution of an external, non-FOSS contract required. But in the early 2000s, Red Hat began experimenting with the use of contributor agreements. Fedora started requiring contributors to sign a CLA based on the widely adapted Apache ICLA, while a Free Software Foundation-derived copyright assignment agreement and a pair of bespoke CLAs were inherited from the Cygnus and JBoss acquisitions, respectively. We even took a few steps towards adopting an Apache-style CLA across the rapidly growing set of Red Hat-led projects.

This came to an end, in large part because those of us on the Red Hat legal team heard and understood the concerns and objections raised by Red Hat engineers and the wider technical community. We went on to become de facto leaders of what some have called the anti-CLA movement, marked notably by our opposition to Project Harmony and our efforts to get OpenStack to replace its CLA with the DCO. (We reluctantly sign tolerable upstream project CLAs out of practical necessity.)
Why CLAs are problematic
Our choice not to use CLAs is a reflection of our values as an authentic open source company with deep roots in the free software movement. Over the years, many in the open source community have explained why CLAs, and the very similar mechanism of copyright assignment, are a bad policy for open source.

One reason is the red tape problem. Normally, open source development is characterized by frictionless contribution, which is enabled by inbound=outbound without imposition of further legal ceremony or process. This makes it relatively easy for new contributors to get involved in a project, allowing more effective growth of contributor communities and driving technical innovation upstream. Frictionless contribution is a key part of the advantage open source development holds over proprietary alternatives. But frictionless contribution is negated by CLAs. Having to sign an unusual legal agreement before a contribution can be accepted creates a bureaucratic hurdle that slows down development and discourages participation. This cost persists despite the growing use of automation by CLA-using projects.

CLAs also give rise to an asymmetry of legal power among a project’s participants, which also discourages the growth of strong contributor and user communities around a project. With Apache-style CLAs, the company or organization leading the project gets special rights that other contributors do not receive, while those other contributors must shoulder certain legal obligations (in addition to the red tape burden) from which the project leader is exempt. The problem of asymmetry is most severe in copyleft projects, but it is present even when the outbound license is permissive.

When assessing the arguments for and against CLAs, bear in mind that today, as in the past, the vast majority of the open source code in any product originates in projects that follow the inbound=outbound practice. The use of CLAs by a relatively small number of projects causes collateral harm to all the others by signaling that, for some reason, open source licensing is insufficient to handle contributions flowing into a project.
The case for CLAs
Since CLAs continue to be a minority practice and originate from outside open source community culture, I believe that CLA proponents should bear the burden of explaining why they are necessary or beneficial relative to their costs. I suspect that most companies using CLAs are merely emulating peer company behavior without critical examination. CLAs have an understandable, if superficial, appeal to risk-averse lawyers who are predisposed to favor greater formality, paper, and process regardless of the business costs. Still, some arguments in favor of CLAs are often advanced and deserve consideration.

Easy relicensing: If administered appropriately, Apache-style CLAs give the project steward effectively unlimited power to sublicense contributions under terms of the steward’s choice. This is sometimes seen as desirable because of the potential need to relicense a project under some other open source license. But the value of easy relicensing has been greatly exaggerated by pointing to a few historical cases involving major relicensing campaigns undertaken by projects with an unusually large number of past contributors (all of which were successful without the use of a CLA). There are benefits in relicensing being hard because it results in stable legal expectations around a project and encourages projects to consult their contributor communities before undertaking significant legal policy changes. In any case, most inbound=outbound open source projects never attempt to relicense during their lifetime, and for the small number that do, relicensing will be relatively painless because typically the number of past contributors to contact will not be large.

Provenance tracking: It is sometimes claimed that CLAs enable a project to rigorously track the provenance of contributions, which purportedly has some legal benefit. It is unclear what is achieved by the use of CLAs in this regard that is not better handled through such non-CLA means as preserving Git commit history. And the DCO would seem to be much better suited to tracking contributions, given that it is normally used on a per-commit basis, while CLAs are signed once per contributor and are administratively separate from code contributions. Moreover, provenance tracking is often described as though it were a benefit for the public, yet I know of no case where a project provides transparent, ready public access to CLA acceptance records.

License revocation: Some CLA advocates warn of the prospect that a contributor may someday attempt to revoke a past license grant. To the extent that the concern is about largely judgment-proof individual contributors with no corporate affiliation, it is not clear why an Apache-style CLA provides more meaningful protection against this outcome compared to the use of an open source license. And, as with so many of the legal risks raised in discussions of open source legal policy, this appears to be a phantom risk. I have heard of only a few purported attempts at license revocation over the years, all of which were resolved quickly when the contributor backed down in the face of community pressure.

Unauthorized employee contribution: This is a special case of the license revocation issue and has recently become a point commonly raised by CLA advocates. When an employee contributes to an upstream project, normally the employer owns the copyrights and patents for which the project needs licenses, and only certain executives are authorized to grant such licenses. Suppose an employee contributed proprietary code to a project without approval from the employer, and the employer later discovers this and demands removal of the contribution or sues the project’s users. This risk of unauthorized contributions is thought to be minimized by use of something like the Apache CCLA with its representations and signature requirement, coupled with some adequate review process to ascertain that the CCLA signer likely was authorized to sign (a step which I suspect is not meaningfully undertaken by most CLA-using companies).

Based on common sense and common experience, I contend that in nearly all cases today, employee contributions are done with the actual or constructive knowledge and consent of the employer. If there were an atmosphere of high litigation risk surrounding open source software, perhaps this risk should be taken more seriously, but litigation arising out of open source projects remains remarkably uncommon.

More to the point, I know of no case where an allegation of copyright or patent infringement against an inbound=outbound project, not stemming from an alleged open source license violation, would have been prevented by use of a CLA. Patent risk, in particular, is often cited by CLA proponents when pointing to the risk of unauthorized contributions, but the patent license grants in Apache-style CLAs are, by design, quite narrow in scope. Moreover, corporate contributions to an open source project will typically be few in number, small in size (and thus easily replaceable), and likely to be discarded as time goes on.
Alternatives
If your company does not buy into the anti-CLA case and cannot get comfortable with the simple use of inbound=outbound, there are alternatives to resorting to an asymmetric and administratively burdensome Apache-style CLA requirement. The use of the DCO as a complement to inbound=outbound addresses at least some of the concerns of risk-averse CLA advocates. If you must use a true CLA, there is no need to use the Apache model (let alone a monstrous derivative of it). Consider the non-specification core of the Eclipse Contributor Agreement—essentially the DCO wrapped inside a CLA—or the Software Freedom Conservancy’s Selenium CLA, which merely ceremonializes an inbound=outbound contribution policy.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
2019年3月6日：开源日报第351期

6 3 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《美化工具 js-beautify》
今日推荐英文原文：《How Artificial Intelligence can Improve Health and Productivity?》

今日推荐开源项目：《美化工具 js-beautify》传送门：GitHub链接
推荐理由：还在为了处理年少时写的 JS 或者 HTML 而一个个的调整 tab 吗？这个项目可以帮助你美化你写的 JS ，HTML 和 CSS 代码。只需要调整一下自定义设置，然后你的代码就能变得非常干净，换行都换的赏心悦目，如果你还在为了一个个整理换行对齐而发愁的话，这个就是一个很好的解决方案。
在线使用版：https://beautifier.io/
今日推荐英文原文：《How Artificial Intelligence can Improve Health and Productivity?》作者：Mindsync
原文链接：https://medium.com/mindsync-ai/how-artificial-intelligence-can-improve-health-and-productivity-1a9e666a9d6c
推荐理由：AI 如何提高人类健康水平和生产力——在有些方面，AI 能够比人类收集更多的数据，从而做的更好
How Artificial Intelligence can Improve Health and Productivity?
Survival instinct is key to the prosperity of the human species. It is perhaps why we as humans have always been a bit hypochondriac deep down. Thus, when people are personally given the responsibility of monitoring their health, they are at a greater advantage.

However, humans have minimal computational capacity in terms of analyzing their physiological data, which are gathered through sensations such as fatigue and pain to name a few. Moreover, they cannot possibly compare this data with various other data sets. This is why, humans are soon going to lose their comparative advantage in the task of reporting their physiological conditions to AI systems.

While it is well established already by various experts that, Artificial Intelligence can help medical and healthcare professionals to carry out diagnosis much more efficiently than before, the role AI can play in personal fitness is something which is being brought to notice recently. The AI-driven medical systems industry is set to grow up to $6.6 billion according to an Accenture report.

Some of the spheres within which AI has been most effectively applied according to a Forbes magazine report are: AI assisted robotic surgery, image analysis, and other administrative and managerial tasks within the health sector. Apart from these, AI has effortlessly assumed the roles of virtual nursing assistants and has been quite successful in aiding clinical judgments.

Since these have shown positive results, all these technologies are to be used by the large scale health industry and will be administered and used by professionals. Meanwhile, the role of patients as passive recipients of treatment will remain the same. Moreover, while these significant changes keep happening in the medical industry, there is another parallel healthcare revolution brewing, and this is aimed at empowering the individual patients.

Many personal fitness gadgets are being developed for the market. When these gadgets are integrated with AI systems, they become capable of providing customized health care solutions for individuals. These will soon offer a far more intense and all-round healthcare option for individuals than any given physician could ever provide.
Wearables and AI: Are you Fitbit Enough?
Wearable fitness gadgets have risen in popularity in spite of the skepticism from doctors about their effectiveness of for instance measuring how many steps any individual has taken. Moreover, there is no denying the fact that devices, like the Apple Watch, Android Wear, and Fitbit among others are producing vast amounts of data related to the health and lifestyle of the users.

The wearables industry has witnessed its fair share of success stories. Kardia, for example, is a case in point. Kardia was successful in developing a cost-effective EKG wearable which collected vast amounts of EKG data from the users. The collected data is then processed through an algorithm which detects atrial fibrillation. The FDA has in fact cleared Kardia’s system as a valid measure for the detection of this cardiovascular condition.

Propeller Health is another successful AI system which was able to detect asthma attacks based on patient medication data and environmental conditions. There are several other examples of such successes.

Therefore, we see that not only is AI capable of producing positive results in terms of providing effective health care; it also is an inevitable option to process the large volume of health data that is generated by the wearable gadgets and other such platforms.

Apart from the wearables, several online platforms which are providing fitness related services are eventually going to benefit the users. Although they depend on human respondents in certain areas of health care, like providing a personal exercise routine or a diet plan fit for weight loss, these services can be of great help.
Conclusion: Health Care Cut to Size
We have already seen how Google Assistant, Siri, or Alexa have used our personal data to make our digital experience more fulfilling. They have technically used their AI systems to create customized song lists, reading lists, and even shopping lists for each user by training them with vast amounts of relevant data sets.

With the importance and need for AI solutions increasing by the day, MindSync is creating a holistic community of the best minds in AI technologies — data scientists, machine learning experts, etc. This community will be a single touch point for all kinds of industries to submit their requirements. These tasks will be taken up by the community as a challenge and the best talent around the world will work towards fulfilment of the business task. The best task can then be used by the business to transform its processes and create a clear competitive advantage.

Experts are of the opinion that this model can be replicated for the health sector as well. By using personal health data of the individuals, the AI systems will be able to create customized lifestyle plans, diets and exercise routines which do not affect the working hours or the personal routine of the users.

The preferences for food or types of exercises can also be taken into consideration while creating these plans. This data will reduce the bias in reporting health conditions and lifestyle choices, including intimate details like the sexual activities of the individuals.

Therefore, such a comprehensive AI system will increase productivity and well-being of individuals. While large scale AI systems used by the medical industry will improve the longevity of individuals, the personal health care sector will enhance its quality.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
2019年3月5日：开源日报第355期

5 3 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《USTC USTC-CS-Courses-Resource》
今日推荐英文原文：《Dev, Ops, and Determinism》

今日推荐开源项目：《USTC USTC-CS-Courses-Resource》传送门：GitHub链接
推荐理由：来自中国科学技术大学的各种课程资源，以计算机与技术类为主。其中涉及了数据库，算法和计算机结构等等各个方面，各位可以从中挑选感兴趣的进行学习。如果想要偶尔换换风格看点技术向以外的东西的话，兴许人文社科类或者物理类可以满足你的兴趣。
今日推荐英文原文：《Dev, Ops, and Determinism》作者：J. Paul Reed
原文链接：https://medium.com/@jpaulreed/dev-ops-and-determinism-966a57e3a5cc
推荐理由：开发人员和运营人员兴许在有些地方的想法上具有相当大的不同
Dev, Ops, and Determinism
I’ve noticed an interesting pattern when discussing incidents with engineers over the years.

One of the topics that invariably comes up is the concept of “root cause,” a notion faithful followers of my Twitter stream know that I have at least a few thoughts about. Many organizations base their entire process of understanding incidents on the concept, and many of the techniques they use to facilitate that understanding, such as “The Five Whys,” are firmly rooted in this concept of a “linearity of events.”

Challenging this idea, and suggesting that in complex systems, this linearity is soothingly deceptive — but deceptive none the less — always prompts in a fascinating discussion, and often times resulting in impassioned arguments that the idea of a root cause is crucial to understanding how incidents unfold.

The interesting pattern I’ve noticed is the way developers react to this idea versus the way operations engineers react: in my experience, developers tend to argue with more veracity that root cause matters and that cause and effect can be concretely established. Operations engineers, on the other hand, tend to nod and engage with the idea that linear narratives of the complex world may be deceptive.

I’ve always wondered why this is: what it is about developers and their experience that tends to make them react to the idea of “root cause is a myth” like an immune system seeking out a foreign agent, while operations engineers tend to at least entertain the idea?

I’m not entirely sure, but I do have an idea, and it has to do with the different contexts in which the two roles go about their daily work.

Developers work with tools that tend to be deterministic: compilers, linkers, operating systems are complex beasts, certainly, but we think of them as more or less deterministic: if we give them the same inputs, we generally expect the same outputs. And if there is a problem with that output — a “bug” — then the way developers go about solving it is to analyze the inputs (either from the user, or to the suite of tools that encompass the development process), find the “error,” and then change the inputs. This will fix the “bug.”

How do I fix the bug? A core assumption of software development: the same inputs reliably and deterministically create the same outputs.

In fact, non-determinism itself is considered a bug: if the unexpected or errant output isn’t reproducible, then developers tend to extend their investigation into other parts of the stack (operating system, network, etc.) that we more or less assume should behave in the same way as long as we can reproduce the inputs… and if it doesn’t, then it’s still a bug. It’s just an operating system or networking bug.

Either way, determinism is a basic, almost unstated assumption of much of the work developers do.

But for any operations engineer who’s spent time racking and stacking hardware in a data center or arguing with a cloud API, this idea of a fully deterministic world (as long as we can map out all the inputs!) is a fleeting notion at best. Venerable Bastard Operator From Hell jokes about sunspots aside, seasoned operations engineers have seen all sorts of weirdness in the physical world and know that even a noisy neighbor can ruin your day.

The Operational reality (complete with tissues… and salt?)

So, poking holes in the notion that there exists a root cause of our incidents, and that tools like “The Five Whys” will faithfully (and repeatably!) lead us to that singular root cause, isn’t that far of a leap to make for operations engineers. In effect, it challenges an idea that when many operations engineers look back upon their own career experience, often times never really matched up with it anyway. So the reaction is different.

I do not, of course, mean to imply that developers’ reactions are silly or stupid, or that they are incapable of understanding how linearity may be deceptive. Seasoned developers are likely to have seen their fair share of non-determinism in the world.

But, I do think the reaction I tend to get from developers in these discussions has to do with the fact that the concept of determinism generally serves them well in the day-to-day execution of their work. And their run-ins with non-determinism aren’t as frequent as operations engineers’ fights with Schrödinger’s cat pawing at their infrastructure.

Ultimately, whether or not this fully explains the reactions I see, it is a potent reminder that the substance of our reactions is a complex amalgam of not only the topic at hand, but numerous other factors too.

And this is important to remember, whether we’re debriefing a single incident, collaborating across a software delivery pipeline, or making sense of our broader world.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
2019年3月4日：开源日报第354期

4 3 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《提示 bullet》
今日推荐英文原文：《10 Programming Terms in Normal Human Language》

今日推荐开源项目：《提示 bullet》传送门：GitHub链接
推荐理由：一个在命令行中帮助你处理输入的 Python 库，包括屏蔽不合法的输入和提供下拉列表等等，最近它还推出了滚动条相关的功能——这意味着你可以在下拉列表中提供更多的选项了。当然了，如果你不希望你的下拉列表过于单调，这个库也给你提供了使用其他样式的可能性……或者往列表里加点表情包也是个好选择。
今日推荐英文原文：《10 Programming Terms in Normal Human Language》作者：Aphinya Dechalert
原文链接：https://medium.com/@PurpleGreenLemon/10-programming-terms-in-normal-human-language-7279d94f3cce
推荐理由：对一些编程常见用语的解释
10 Programming Terms in Normal Human Language
Learning programming is like learning a completely different language. It gets even worse for a person coming into the field to be bombarded by long tutorials littered with words that makes no sense.

All the words below have more than a million words written about them. But we don’t have the brain capacity or time to process such a massive amount of information. Today, I’ve tasked myself with explaining each concept as simply as possible.

So here’s a quick and concise decryption of commonly used words in programming.
1. Immutable
Immutable is another word for unchanged. If a state is said to be immutable, it means that it’s not supposed to change. Whatever value you’ve set is not going written over or have the potential of changing.

In JavaScript, const is a way to partially declare an immutable value. You can still change the value of const but it takes a bit more work and thinking than let and var.
2. Object
An object is a structured set of code written in a certain way to specify a set or category of things. It is a blueprint for an instance of that particular thing.

People use objects to create more of the thing. They create new objects, assign values to it and use the methods (aka written functionality) to do things with the instance of the object.
3. Prototype
It looks like an object. It smells like an object. People often mistake it as an object. But it’s not an object.

A prototype is the instance itself but replicated. While an object is the plan for the thing, a prototype is the thing with the ability to be extended with features.

The easy way to get your head around it is that an object gets used to create and a prototype is used to create.
4. First Class Function
A function that’s treated like a variable.

This means you can have a function inside a function and set it up like a variable.
5. Recursion
A function, procedure or algorithm that calls itself.

For example, a for loop is a recursion. Main component of a recursion is the thing that kick starts it off and a condition that ends it — or else it will just keep calling itself until the program crashes.
6. Encapsulation
The thing that ring fences off a group of methods or data from outside access.

Encapsulation keeps things local and private inside a conceptual box.
7. Polymorphism
The ability for that same thing to be lots of other things.

For example, an object is polymorphic because it is a blueprint where unique variables can be set for multiple instances of it.

Cats are polymorphic. They’re all still cats but with different appearances and personalities. A stormtrooper’s armor, however, is not polymorphic because they’re all the same.
8. Inheritance
The same concept as inheritance with money.

The child inherits whatever the parent has/is. Inheritance is the act of the child taking on the values and properties of the parent.

In most languages, inheritance flows inwards — meaning that the flow of inheritance goes parent to child and not the other way around.
9. Data Type
Naming what kind of data it is you’re setting.

JavaScript is a loosely typed language. This means that you don’t have to tell it what kind it of data type it is, you just have to tell it that it’s a value to be stored. This is done through var, let and const.

Java is a strongly typed language because you have to tell it exactly what the thing you’re setting is — that is — boolean, char, short, int, long, float or double etc.
10. Persistence
It sticks around. If you go back to it, the thing is still there.

For example, a declared variable and an instance of an object has persistence because it’s still there if you call it again.
Final Words
If you can’t explain it simply, you don’t understand it well enough – Albert Einstein All the concepts above started off as one liners from their creators. But over time, more words have been added to them to test, extend and expand on the idea. There’s nothing wrong with that either — but that can be overwhelming and intimidating for new developers. I was there myself half a decade ago and I know the feeling.

I hope that in condensing it back down, it’s made life a little bit easier for you.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/