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

开源日报第714期：《面试 fe-interview》

12 3 月, 2020
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《面试 fe-interview》
今日推荐英文原文：《Can We Measure Software Developer Productivity?》

今日推荐开源项目：《面试 fe-interview》传送门：GitHub链接
推荐理由：书到用时方恨少，面试的时候一问三不知可一点都不好。如果想要在这个学期结束后找实习或者找工作的话面试自然需要好好准备，这个项目提供了前端方向的面试题目，不仅有考验技术实力的概念题，同样也有考验理解能力的理解题，趁着现在能积累经验的时候尽可能的积累经验，每天来几篇这个题目考验一下自己也是个好事，保持每天学习的好习惯。
今日推荐英文原文：《Can We Measure Software Developer Productivity?》作者：Derwin Dexter Sy
原文链接：https://medium.com/swlh/can-we-measure-software-developer-productivity-f1c43cb6ce70
推荐理由：现在量化生产力似乎没有一个很好的指标
Can We Measure Software Developer Productivity?

Short answer: I don’t know.

What we can easily get is data, not information. Data is just a bunch of numbers. Information, on the other hand, is something that takes human processing to figure out. Photo by William Warby on Unsplash
Short answer: I don’t know.
Before you move on though, I’d like to say that “I don’t know” here means that I know from personal experience that trying to measure a software developer’s productivity rarely (or never) ends well. However, I also acknowledge that, historically, there have been valiant efforts that worked to some extent, and there are likewise promising ideas today that are making the rounds towards addressing the problem.

I’ll run down most of these things here, and I do hope this helps someone out there find a good way to measure productivity (or any other indicators, for that matter) in a way that makes sense in their context.
The Holy Grail
Finding a good way to measure productivity for software developers has always been a “holy grail” of sorts. Many have tried, few have succeeded. And the reason for this is much more obvious these days than it was when software development (or “computer programming”, as they used to call it) was a young field.

Here’s a relevant quote from jazz legend, Miles Davis, on what makes a great jazz tune.
“It’s not the notes you play, it’s the notes you don’t play.” – Miles Davis
This same message holds true for software code. In its early days, software development used to be considered “production” work, not much different from building a house or manufacturing hardware. This line of thought still exists today with most non-technical stakeholders and even with some who have been working in this field for a while. More and more people, however, are starting to realize that software is not exactly construction work, but is, in fact, closer to a pursuit of creativity.

In this sense, just like notes in a tune, the code you don’t write is just as important as the code you write.
Sorry, what?

The code you don’t write is just as important as the code you write. Photo by Chris Ried on Unsplash

If that’s a little bit too abstract, let me explain a few ways this manifests:
- Long code. This is often an indicator of code that can be improved. If you can do the exact same thing with fewer lines of code, you can save on binary space and perhaps your own time. (Be careful not to compromise on readability though.)
- Reinventing the wheel. “There’s just too much software to write for one company to write it.” This is why open source is a thing. If someone has already done it before and it works, you should reuse that as much as you can. If you can use it as a black box library (as opposed to copying the code), that’s a few less lines of code for you to maintain in the future.
- Cognitive load. The most satisfying code is often that which took you hours to think about and a few minutes to type out. You might be able to write entire classes effortlessly if it’s something you’ve done a million times. But writing an efficient 5-line algorithm for something alien to you might take just as much, if not more, of your time.
In addition, writing more code actually means a higher risk of inadvertently writing a bug somewhere. Likewise, if your code is long enough that other people don’t bother reading it, it’s probably worth considering just abstracting it altogether.

In short, measuring “volume of work” to understand productivity just doesn’t make sense anymore, since volume in any tangible form hardly correlates to effort and quality.
So basically “no”?

The fact that people kept coming up with new ways to measure it says a lot about just how important it is to a lot of people. Photo by William Iven on Unsplash

The industrialist in me doesn’t want to admit that there’s no way to measure software developer productivity. As much as I believe that creativity is important in software, I’d also love to be able to tell a customer that we’re halfway done and actually mean it.

Historically, measuring productivity for software developers has been a long and arduous road — from measuring lines of code (definitely rewarding the wrong things) to function points (overly conceptual and complicated) to velocity (not exactly a measure of productivity, but a decent basis for estimations). Each one works in certain contexts, but as software evolved (and it evolved fast), some eventually became irrelevant.

However, just the fact that people have kept coming up with new ways to measure it says a lot about just how important it is to a lot of people.
The future of code metrics
There seems to be some hope. Companies like GitPrime and Waydev are coming up with new Git-based metrics that might make more sense in the way we do software work today. For example:
- Code churn means the volume of code that has been modified less than 30 days from its first commit. This indicates that we might be doing a lot of work that’s volatile and essentially make very little impact on a business level.
- Review coverage is, in the spirit of collaboration and collective learning, a measure of how much code each developer reviewed.
- Impact is, well, something I don’t fully understand. According to the documentation, it should correlate to “cognitive load”, which means how much thought might have gone into coming up with a certain commit (regardless of whether it’s an edit, an addition, or a removal). Disclaimer: There’s probably a lot more to it that I’m not fully grasping.
These and other metrics, in my limited experience with these tools, do seem very promising. I think the naming, particularly “impact”, could be better. Because whatever these metrics indicate, they definitely don’t indicate anything particularly good or bad. They might, however, represent certain trends and behaviors that we can choose to look further into.

I guess what I’m saying is, maybe we should be focusing less on “metrics” and more on “indicators”. What we can easily get is data, not information. Data is just a bunch of numbers. Information, on the other hand, is something that takes human processing to figure out. Whatever the numbers seem to indicate, we need to interpret them in the context of our actual work and our organization. Most importantly, we definitely should stop making these metrics a competition.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第713期：《中文OCR:chineseocr_lite》

11 3 月, 2020

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《中文OCR:chineseocr_lite》
今日推荐英文原文：《Meet Your Match: AI Finds the Right Clinical Trial for Cancer Patients》

今日推荐开源项目：《中文OCR:chineseocr_lite》传送门：GitHub链接
推荐理由：超轻量级中文ocr，支持竖排文字识别, 支持ncnn推理 , psenet(8.5M) + crnn(6.3M) + anglenet(1.5M) 总模型仅17M. 轻量,有效解决痛点.
今日推荐英文原文：《Meet Your Match: AI Finds the Right Clinical Trial for Cancer Patients》作者：ISHA SALIAN
原文链接：https://blogs.nvidia.com/blog/2020/03/08/intrepida-ai-cancer-clinical-trials/
推荐理由：这篇文章为我们简单的介绍了人工智能为癌症患者找到正确的临床试验的过程,可以让我们更好的了解这些前沿技术的具体应用.
Meet Your Match: AI Finds the Right Clinical Trial for Cancer Patients
Clinical trials need a matchmaker.

Healthcare researchers and pharmaceutical companies rely on trials to validate new, potentially life-saving therapies for cancer and other serious conditions. But fewer than 10 percent of cancer patients participate in clinical trials, and four out of five studies are delayed due to the challenges involved in recruiting participants.

For patients interested in participating in trials, there’s no easy way to determine which they’re eligible for. AI tool Ancora aims to improve the matchmaking process, using natural language processing models to pair patients with potential studies.

“This all started because my friend’s parent was diagnosed with stage 3 cancer,” said Danielle Ralic, founder and CEO of Intrepida, the Switzerland-based startup behind Ancora. “I knew there were trials out there, but when I tried to help them find options, it was so hard.”

The U.S. National Institutes of Health maintains a database of hundreds of thousands of clinical trials. Each study lists a detailed series of text-based requirements, known as inclusion and exclusion criteria, for trial participants.

While users can sort by condition and basic demographics, there may still be hundreds of studies to manually sort through — a time-consuming process of weeding through complex medical terminology.

Intrepida’s customized natural language processing models do the painstaking work of interpreting these text-heavy criteria for patients and physicians, processing new studies on NVIDIA GPUs. The studies listed in the Ancora tool are updated weekly, and users can fill out a simple, targeted questionnaire to shortlist suitable clinical trials, and receive alerts for new potential studies.

“We assessed what 20 questions we could ask that can most effectively knock a patient’s list down from, for example, 250 possible trials to 10,” Ralic said. The platform also shows patients useful information to help decide on a trial, such as how the treatment will be administered, and if it’s been approved in the past to treat other conditions.

Intrepida’s tool is currently available for breast and lung cancer patients. A physician version will soon be available to help doctors find trials for their patients. The company is a member of the NVIDIA Inception virtual accelerator program, which provides go-to-market support for AI startups — including NVIDIA Deep Learning Institute credits, marketing support and preferred pricing on hardware.

Finding the Perfect Match

Intrepida founder Danielle Ralic

Though the primary way patients hear about clinical trials is from their physicians, less than a quarter of patients hear about trials as an option from their doctors, who have limited time and resources to keep track of existing trials.

Ralic recalls being surprised to meet a stage 4 cancer survivor while hiking in Patagonia, and finding out the man had participated in a clinical trial for a new breakthrough drug.

“I asked him, how did you know about the trial? And he said he found out through a relative of his wife’s friend. That’s not how this should work,” Ralic said.

For physicians and patients, a better and more democratized way to discover clinical trials could lead to life-saving results. It could also speed up the research cycle by improving trial enrollment rates, helping pharmaceutical companies more quickly validate new drugs and bring them to market.

As members of the NVIDIA Inception program, Ralic says she and the Intrepida team were able to meet with other AI startups and with NVIDIA developers at the GPU Technology Conference held in Munich in 2018.

“We joined the program because, as a company that was working with NVIDIA GPUs already, we wanted to develop more sophisticated natural language models,” she said. “There’s been a lot to learn from NVIDIA team members and other Inception startups.”

Using NVIDIA GPUs has enabled Intrepida to shrink training times for one epoch from 20 minutes to just 12 seconds.

Diversifying the Data

A female startup founder in an industry that to date has been dominated by men, Ralic says more diversity is key to improving the healthcare industry as a whole — and especially clinical trials.

“Healthcare is holistic. It involves so many different types of people and knowledge,” she said. “Without a diversity of perspectives, we can never address the problems the healthcare industry has.”

The data backs her up. Clinical trial participants in the United States skew overwhelmingly white and male. The lack of diversity in trials can lead to critical errors in drug dosage.

For example, in 2013, the U.S. Food and Drug Administration mandated doses for several sleeping aids to be cut in half for women. Because females metabolize the drug differently, it increased their risk of getting in a car accident the morning after taking a sleeping pill.

“If we don’t have a diverse trial population, we won’t know whether a patient of a different gender or ethnicity will react differently to a new drug,” Ralic said. “If we did it right from the start, we could improve how we prescribe medicine to people, because we’re all different.”

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第712期：《百度网盘 BaiduPCS-Go》

10 3 月, 2020

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《百度网盘 BaiduPCS-Go》
今日推荐英文原文：《What They Don’t Tell You in College About Being a Software Developer》

今日推荐开源项目：《百度网盘 BaiduPCS-Go》传送门：GitHub链接
推荐理由：用 Go 语言编写的百度网盘，打开终端，这次我们换一个网盘的打开方式吧，没准还能快一点呢。
今日推荐英文原文：《What They Don’t Tell You in College About Being a Software Developer》作者：Steven Popovich
原文链接：https://medium.com/better-programming/what-no-dont-tell-you-in-college-about-being-a-software-developer-cda2d3f581bc
推荐理由：大学给了我们时间，当然，它并没有教会我们全部。
What They Don’t Tell You in College About Being a Software Developer

College doesn’t prepare you for everything in software development

(Photo by Georgie Cobbs on Unsplash)
So, you just graduated college and you landed your first software engineering job. Congratulations!

Or, maybe you are still in college studying software. Yeah, it sucks, but keep going; it’s valuable.

Or, maybe you are thinking about a career switch to writing software. I get it, it is a nice field to be in.

If you are in any of these boats, I want to impart some of my experiences and what I have learned in my first eight months of writing software.

Focusing 40 Hours a Week Indefinitely Is an Adjustment
College is inherently a fairly scattered-brain thing. You are managing different classes on different topics, different groups, maybe a job, and extra-curriculars.

Full-time work is not. You still have some variety in what you do, but you have one title at one company (probably). And in a lot of ways, it is really nice to have just one thing to focus on.

But in other ways, it is harder. You have to sit down and focus 40 hours a week. Every week. No more attempting homework then texting your buddy for help. You can’t blow off assignments because you got a high grade on the last test.

You can socialize at work, but you can’t invite your buddy over to work on the project and end up cracking open some beers. You have to focus for long periods of time, especially in our field.

It can be exhausting. Especially when you are new and you don’t know what you are doing.

I mean, look, you get time off and you have lunch and water cooler talk, but it is not like college. I graduated in engineering without ever focusing for 40 hours in a week, I can tell you that. Well, at least not multiple weeks in a row.

It is different. And it is hard. To be honest, I still don’t like it. I am used to it, but some weeks are harder than others.

Sometimes, at 4:30 or 5:00, I’ve just got to stand up and shoot the shit with someone. I can (and do) work more than 40 hours a week, but it just isn’t easy.

Maybe 40 hours a week is too much?

You Have to Adopt a Need-to-Nerd Attitude
You don’t know shit. I don’t know shit. I thought I knew shit. I realized I didn’t know shit.

You will be given projects and tasks that you don’t know how to do. You will have never done anything like it before.

You will have to learn about the framework. You will have to learn about how (or if) your company has approached this problem in the past. You get the point.

The bottom line is: Employed engineers learn. Good engineers learn.

Given a task to improve the battery performance of your app? Better learn how to see what in your app is taking up so much battery. Google it. Reference a textbook. Ask coworkers. Ask Stack Overflow. Take ownership of your task and learn how to do a good job of it.

See, in college, you are given what to learn. You are given the pages to read. You learn facts but you don’t get to make truly critical analyses.

In software, you have to constantly make objective analyses about what the best way to solve a problem is. You have to learn about the domain of the problem. You have to do more than just complete the assignment. It is a holistic process that isn’t emulated well outside of the real world.

But you can’t learn everything. Ever try to read a textbook cover to cover? I have. I was trying to learn everything about a platform I was working on. It didn’t work. I didn’t retain anything. It wasn’t directly relevant to what I was doing day-to-day and I wasn’t applying what I was reading.

You don’t need to learn everything, but you do need to learn about the code you are working on. You need to learn frameworks, languages, and patterns on a need-to-nerd basis.

College Is Hard, but So Is Writing Good Software.
I really thought writing code would be so fun all the time. And it is fun most of the time. But as I learn more about writing code that scales, clean code, architecture, and writing code that other people can work on, I realize there is a lot to learn. And a lot to practice.

To write good code, you need to focus. You have to learn about the language you are working in. You have to rewrite and refactor code. You have to be critiqued by your co-workers. You will get better, but writing good code is hard work.

The bottom line is that you work for a business and businesses need to make money. They do this by (most likely) providing distributed software systems to thousands of users. Systems with lots of features. With codebases that grow over years.

Large codebases are hard to work on, they just are. No matter how well they are written. And extending them in a cohesive way is inherently difficult and takes years of practice to do effectively.

It’s worth it though! I don’t want to sound negative. I love my job. I love what I do and where I work. Seeing a beautiful, well-formed system function at scale is a great feeling and is part of the reason we got into the field in the first place.

Ask Every Question. And Don’t Be Afraid to Pair
I came into my first real engineering job with some experience. I had written code that made it into production in a couple of different internships and contracts. I knew I was coming into a new domain, but I wanted to figure things out for myself. But boy, I was missing out.

I severely underestimated the value of being surrounded by engineers that are better than me. They have forgotten more things about programming than you know. Use these resources.

Now there is a balance to be struck. There is huge value in figuring things out for yourself. You have to sit down and do things yourself to learn. But after a half-hour of banging your head against the wall, ask for help and pair.

Having someone write code next to you does not make you a bad developer. There is actually a lot of research that shows pair-programming can be beneficial to both programmers, lead to better code, and is faster than working by yourself. Here is a nice report that I really like.

In the same vein, as you learn more about the system you are working on or learn new languages, you will have questions. A lot of them.

Use your best judgment about who to ask, be polite and ask, ask, and ask. It can only help you. Looking dumb does not exist when you complete tasks because you are asking the right questions.

Every single engineer asks questions. It is part of our job. We question what is the right way to do something every day. It is how quality software is written.

You Have to Practice Everything
Full-time work allows you to focus on one thing for the first time in your life. You might have a couple of different projects at work, or meetings, but you have one job to get better at. You have sole responsibility.

It is a far cry from taking five different classes, being in two clubs, and being a part of three different workgroups. Not to mention three of your classes are in history, art, and public speaking, for some reason.

Being in the same place every day makes your shortcomings more transparent to yourself.

Maybe you don’t like working in groups. Many programmers don’t. It’s OK.

Maybe you don’t respond to email or Slack very well. I just want to code.

Maybe you don’t participate in meetings. I get it, meetings are boring.

But you realize these things with repetition. And like writing code, you have to practice the soft things. You can get better at communication, listening, participation, timeliness, initiative, whatever! And you should.

Take notes about yourself in a meeting. For regular meetings, think about what you can do beforehand to make the meetings go faster for everyone. Jot down things to bring up later in water cooler conversations, like your co-worker’s new dog or their new apartment.

Being a software developer is more than writing code. You have to be a teammate too. I have seen myself try to and succeed at getting better at being a teammate. I just needed to practice.

Time Moves Faster and Habits Are Critical
This is a weird one. People say time moves faster when you get older, but I think time moves faster when you work full time. I am also not that old, I guess.

I think it comes from your reference and timeline shifting significantly. All of a sudden, it’s not the test coming up in a week, it’s when your lease ends in three months. It’s the deadline you have to meet in a month.

You think about the rest of your life more instead of one semester at a time. You think about your company’s indefinite future. It changes your perspective quickly.

I mean, in college, all I planned for was finishing and getting a job. That’s four or five years, max. Then, all of a sudden, you get a full-time job and you start thinking about retirement, why are all your friends getting married, why can’t you grow a beard yet…I digress.

The point is, the phenomenon of time moving faster is true. And to that point, I think the formation of habits becomes more critical.

For possibly the first time in your life, you have an indefinite structure. The same schedule almost every day. This is a great opportunity to build good habits, like exercising or packing healthy lunches.

It is important to start with good habits sooner rather than later. It can be so easy to fall into bad habits.

Starting full-time work is a great time to stop exercising. It is the time in life where people start to gain weight. Turns out it isn’t just because you are getting older.

Thanks
Thanks for reading! I hope you take some of these to heart. I love my job. Continue working for that full-time job, it is worth it!

下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第711期：《牧羊人 shepherd》

9 3 月, 2020
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《牧羊人 shepherd》
今日推荐英文原文：《What I learned from my first 3 years of leading an R&D group》

今日推荐开源项目：《牧羊人 shepherd》传送门：GitHub链接
推荐理由：对于一个网站来说，一个指南可以让用户更好的了解网站信息。这个项目正是一个可以让你引导用户的指南库，它支持纯 JS 以及流行框架 React，Vue 等等，便于与各种已有项目结合使用，提高用户使用体验。
今日推荐英文原文：《What I learned from my first 3 years of leading an R&D group》作者：
原文链接：https://medium.com/@bendanon/what-i-learned-from-my-first-3-years-of-leading-an-r-d-group-416f7971ec5f
推荐理由：作者在工作中的经验分享
What I learned from my first 3 years of leading an R&D group
Its been almost three years since I started my role as an R&D group leader in the Israel Defense Forces (IDF). My group counts 6 teams, averaging around 5 software developers each. In this post I will summarize my retrospect and learning with the hope of giving other managers some pointers to things that were most helpful to me.
1. Trust over Authority
First and foremost, establish trust. when your people trust you and believe everything you do is with their best interest in mind, they will reciprocate by keeping you and your goals in mind when making every day decisions. They will forgive your mistakes and do their best to make your life easier. This is invaluable.
- Have regular One-on-Ones: Weekly 30 minutes meetings with your directs are the single most important thing you can do as a manager and they are the basis for trust. They provide the platform for a deep personal connection (dare I say friendship), giving mutual feedback, talking about growth, fears, stress and anything that comes up during or outside work. If I had only 3 hours of work next week, I would invest them in 1–1’s with my team leaders.
- Be open about your mistakes: Try and insert your mistakes into conversations. Get used to talking about your shortcomings. Give people the space to learn and the confidence to try new things and make commitments by showing that its okay to make mistakes and be honest about them.
- Be around and available: Managers are always busy people, but you shouldn’t be too busy to approach. Keep an open and updated calendar, make sure your people know when is the next time they can catch you for a chat, and make sure its within the next day or two. Try to physically present as much as possible, without hovering. Respect your schedule and the schedule of your people, even if it means cutting meetings short.
2. Create a platform for your people to thrive

The purpose of your management role is for your business unit to bring maximum value to your organization. The most efficient way to do that is to have your people thriving in their roles. Therefore, you should invest your time in creating a platform for them to thrive by mentoring / coaching, providing positive and constructive feedback, forming healthy teams and work environment, providing resources and learning opportunities, extending challenges, clarifying what success looks like and pointing to the right direction, celebrating success, aligning personal and business goals, hiring and promoting according to company values.
3. Make your goals clear
It is far from straightforward to form coherent goals and priorities, let alone to communicate them to your people. Keep in mind that if a goal is incoherent to you, it comes across as confusing at best. Even if it’s coherent to you, people won’t internalize it the first time you present it. You should make it a priority to set your goals and priorities straight, using your people, your peers, external resources, mentors etc. Once you have your goals figured out make sure you clearly communicate them using many formats and mediums, and don’t be afraid of repetition.
4. Be an information hub
Don’t just “stay in the loop” with the day-to-day. Be an information hub. Create friction-less methods for important information to automatically float to you (e.g. using JIRA dashboards, crafting issue filters, following changes in important documentation pages, etc). Talk about the critical subjects with multiple people to ensure alignment, digest and publish written information such as meeting notes and important discussions so that everyone can make use of it. Follow what people are doing and make connections between people that can benefit each other to facilitate cooperation and teamwork.
5. Value your people’s time
Don’t be a time waster manager. Don’t demand your approval for things. Try and avoid big and elaborate meetings as much as possible and keep close tabs on the time your people spend doing things you specifically asked them to do. Your people are intelligent, creative and independent thinkers and they should feel in control of their time. Nothing is more counter productive than robbing them of their time for working on the things they believe are important for the organization.
6. Stay hands-on
Stay curious about the actual work. Invest time in deepening your knowledge about the technological challenges your people face. Most people like teaching and will appreciate management taking the time to learn more about their problem space. It will also keep you from dogmatic thinking, help you with decision making, keep you updated and developing your knowledge, and make it easier for your people to explain stuff to you when needed.
7. Read a LOT
Many of my management “tricks”, some of them written above, came from reading stuff online and adapting them to me. Maintain constant growth for your management skills, always try and learn new things. Don’t stagnant. Read the comments for a short list of resource recommendations.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/