开源日报第902期：《人类时间 HumanizeDuration.js》

21 9 月, 2020
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《人类时间 HumanizeDuration.js》
今日推荐英文原文：《The Software Engineer’s Guide to Avoid Work-From-Home Burnout》

今日推荐开源项目：《人类时间 HumanizeDuration.js》传送门：项目链接
推荐理由：在代码里，绝大部分时候时间都以毫秒的形式存在，但是一旦时间需要显示给用户，就需要把毫秒转换为时分秒这样简单易懂的单位。这个项目可以帮你实现这一点，同时还额外提供了改变输出使用的语言与对输出格式做细微调整的功能，比当场手写实现一个要方便的多。
今日推荐英文原文：《The Software Engineer’s Guide to Avoid Work-From-Home Burnout》作者：Ekrem Aktaş
原文链接：https://medium.com/better-programming/the-software-engineers-guide-to-avoid-work-from-home-burnout-b5d887601641
推荐理由：一些能改善在家中工作产生的不便的建议
The Software Engineer’s Guide to Avoid Work-From-Home Burnout

Strategies to improve your productivity and happiness at home
Software engineering is one of the most suitable professions for working from home (WFH). But even though software engineers seem to enjoy working from home, there are signs that it may decrease productivity. For example, a case study reports that WFH might hurt developer productivity on large projects. Another analysis performed by Microsoft on its employees working from home found a new “night shift” forming up — often to catch up with work, leading to burnouts.

There are many aspects of WFH that can decrease your productivity and cause burnouts, but I want to focus on two of them.

The first is avoiding distractions and keeping yourself focused on the task. Focusing and being in the zone is the ultimate recipe for productivity. But focusing on the work in your room is not trivial when large tech companies are racing to get your attention with every notification popping up on your phone or your kids demanding your attention.

The second problem is communication. Many companies met with remote work for the first time in the COVID-19 pandemic and didn’t have a remote-first work culture. Most of them are still operating WFH with the “office” mindset, which depends on synchronous communication. But the companies with a remote-first culture, such as GitLab and Basecamp, embrace asynchronous communication instead. Unfortunately, most software engineers now need to adapt to WFH with “office” culture until their companies embrace asynchronous communication.

As a software engineer, those issues can decrease your productivity. Here is a list of suggestions to tackle them.
Take Zoom Meetings Outside
Virtual meetings decrease your productivity for two reasons: Keeping yourself focused during virtual meetings is tough, and many things can distract you.

Do you “zoom out” while having meetings on Zoom? You’re not alone. Focusing on a virtual meeting requires more effort than a regular meeting. Staring at the screen and camera simultaneously for hours to show that you’re paying attention is exhausting. It even has a name: Zoom fatigue.

Did you ever notice the person who works secretly during Zoom meetings? You can easily see that from their face, which often looks dull and steady. No, don’t blame the victim here. It’s easy to fall into the trap of multitasking — many people do it while checking out the notifications on their phones as they speak to friends.

Did you have a “no laptop during meetings” rule back at the office? Some companies have it to ensure that people aren’t distracted with their work during meetings. But that’s what we do during virtual calls. We join meetings with laptops. Unfortunately, we join them without even leaving the table. Walking over to a meeting room in the office helped us switch context from whatever we were working on to the meeting’s agenda. That’s no longer the case with virtual meetings, and we have a hard time switching context without standing up from the chair.

Have you ever tried having a physical conversation with a person looking at your belly instead of your eyes? Go ahead and try it. That’s what we do every day on Zoom.

All the difficulties above have two common parts: video and distractions. And here is a controversial solution: Join a Zoom meeting from your phone with video disabled, and go outside.

When you join a Zoom meeting without video, your meeting turns into a phone call. Phone calls feel more natural than video conferencing to us because we’ve practiced them since we were kids. Now you can focus on the meeting without looking at the same region of your screen for an hour.

Taking a stroll outside the house with Zoom meetings has many benefits.

First, you get rid of all distractions that your workstation can cause. You don’t have to look at a screen. There are no unread emails or Slack messages. Your phone is in your pocket (hopefully). It is you and your headphones. You can focus on what you hear in the meeting.

Second, walking is a real life hack. That’s not because it’s healthy but because it helps you think better, increase your working memory, and boost your creativity. You increase your productivity and cognitive abilities by walking because your heart pumps more blood than sitting. Your brain takes advantage of the extra blood flow. You become smarter by walking. Why not take advantage of this with meetings that need mental power?

And lastly, you feel better when you take a walk outside, helping you cope with the WFH burnout.
Have a Zoom Meeting Running in the Background With Your Teammates
Focusing on work is easier when you work with others. That’s why pair programming works — it helps both the driver and the navigator stay in the zone, and makes them less vulnerable to distractions.

You can apply a similar technique by having an always-on Zoom meeting with your teammates, but with everyone muted. This helps to simulate an “office” environment. Everyone can focus on their tasks, like in the office. Anyone with a question can unmute and start a conversation at any time.
Limit Hours in Meetings
A benefit of remote work is that we don’t need meeting rooms anymore, but that’s also a curse. Previously, meetings were limited by the physical availability of meeting rooms. We used to postpone meetings when there were no available rooms.

When a resource is scarce, you care more about how you use it. There wouldn’t be useless or optional meetings, just because finding a room was hard.

With WFH, you are always working from the “meeting room” because the physical constraints no longer apply. Teams can have meetings at any time, anywhere. A study performed by Microsoft reports that “too many meetings” is the number one challenge software engineers encounter during WFH.

Limit the time you spend on meetings daily. Schedule the available time slots left in your calendar once you’ve reached your meeting limit for the day. This way, meeting organizers will have an incentive to choose another day where you’re available for meetings.

Another approach is to declare meeting-free days. Microsoft reports that 73% of participants said “No-meeting Friday” improved their wellbeing and 77% reported it gave them more focus time. Of course, this is not something you can decide for yourself, but you can start a conversation in your company.
Work on the Most Important Task First, and Make Sure You’re Not Interrupted
Back in the days when I was working in the office, I used to start my day by “catching up,” checking my inbox and pending Slack messages first. I could easily spend an hour with it. Now I realize that it was a total mistake.

According to research, we are self-distracters: We check our email and IM every six minutes, thus hijacking our focus. It is more hazardous when you check pending notifications at the beginning of your workday because you lose control of your day from the beginning. You often respond to the pending messages immediately and may spend hours on tasks that you did not plan for your most productive time slot.

Instead, treat the first two hours of your working day as focus hours. Dedicate this time slot to work on the most important and challenging task that requires focus and cognitive power. This is a sacred time slot: no notifications or distractions are allowed. Things you can do during the focus hours:
- Silence all IM and email notifications
- Write code for challenging stories
- Perform non-trivial code reviews
- Write technical decision documents, such as ADRs
- Debug a rather complicated bug
- Brainstorm about a problem you want to solve
Avoid doing these below during focus hours:
- Arrange or attend meetings
- Read unread messages on Slack, JIRA, or Zendesk
- Work on trivial stories
- Any repetitive or monotonous work/task
- Check social media/news
You will feel productive by working on the most crucial task first, even if you’re not productive during the rest of the day.

You may ask, “shouldn’t I respond to a Slack message when one of my team members sends a direct message asking for help?” Indeed you should. But it is best if you make sure that you don’t get that message by starting your workday earlier than your teammates. For example, I dedicate the time between 7:30 a.m. and 9:30 a.m. to focused work.
Plan Your Day the Day Ahead, and Schedule Time Slots on Your Calendar
Take a short break after the focus time and plan the rest of your working day. Briefly check emails and Slack messages from the previous day to create a plan. Prioritize your work backlog and focus on what matters the most. Schedule a time slot for each activity on your calendar, which will help you manage time and prevent last-minute meetings. Don’t forget to plan for breaks during the day; otherwise, you may fall into the trap of working the whole day without a break.

A plan of your day could look like this: 11:00–12:00: Code for story #1 13:00–13:30: Triage ticket #2 13:30–14:00: Break 14:00–15:30: Pair with a teammate on a story 15:30–16:00: Review pull request #3 Don’t worry if your day doesn’t go as planned. Just take note of what happened instead. Deviations from your original plan are excellent opportunities to learn retroactively what your actual workday looks like. They often indicate the things holding you back from being more productive. Maybe it’s time to fix that CI pipeline, which fails intermittently and causes you to lose time.
Plan Short and Well-Defined Stories
Coding alone is very natural to software engineers, until they don’t know the requirements or encounter a problem.

Imagine that you are working on a task and have a question about the scope or feature. Walking by a teammate is quite natural and comfortable, thanks to open floor plans when working at the office. But that changes with WFH because collaboration and communication are more challenging when working from home. The communication is asynchronous, meaning you might get blocked until you get a response.

Ensure that each story you’re going to pick up has a clear definition of “done” and of scope. It should also include the technical implementation approach and details, leaving less room for unclarity. Writing small ADRs whenever applicable is a great way to achieve this. Otherwise, include it in the description. This way, a software developer can complete a story without getting blocked and requiring less external help. The impact of having explicit stories is more observable, especially with junior engineers.
Share the Knowledge
WFH productivity changes depending on the size and the age of the project. While small or newer projects benefit from increased WFH productivity, the benefits shrink with large or old projects.

The reason is that large and old projects contain more information to be processed by everyone in a team, therefore requiring more communication. The scope is enormous, and there is often no single person who holds all of the information in their head. We rely on multiple people’s knowledge about specific parts of the project to complete our work. We ask questions of the people who are most likely to know the answer. Limited communication caused by WFH might be causing the productivity decrease for large projects.

To cope with this problem, share the information regularly. Schedule knowledge-sharing meetings to inform team members about the project. Record your meetings so that people can watch them on demand later on.

Another way of sharing knowledge lies in your commit messages. Software developers often browse the repo history to figure out how the code evolved and why a particular code exists. More explanatory and informative commit messages can help any future developer understand your perspective and reasons for a specific commit.

I hope these strategies can help you to become more productive at home and resilient to WFH burnout. Thanks for reading!
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/

开源日报第901期：《Linux Command》

20 9 月, 2020

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《Linux Command》
今日推荐英文原文：《56 Funny Code Comments That People Actually Wrote》

今日推荐开源项目：《Linux Command》传送门：项目链接
推荐理由：该项目现在搜集了 570 多个 Linux 命令，是一个非盈利性的仓库，并包括 Web 版本、Chorme 插件、Alfred版本等等，是非常值得收藏的 Linux 命令速查手册。

今日推荐英文原文：《56 Funny Code Comments That People Actually Wrote》作者：Nehal Khan
原文链接：https://medium.com/better-programming/56-funny-code-comments-that-people-actually-wrote-6074215ab387
推荐理由：程序员迷惑行为大赏。

56 Funny Code Comments That People Actually Wrote

These are actually in a code base somewhere

Code comments are a human-readable explanation of what a computer program does. They are added to make the code easier for humans to understand.

Well, in this article, you will see how code commenting can be funny, too. Here is a list of comments that were actually written in the code.

1.

/*
 * Dear Maintainer
 *
 * Once you are done trying to ‘optimize’ this routine,
 * and you have realized what a terrible mistake that was,
 * please increment the following counter as a warning
 * to the next guy.
 *
 * total_hours_wasted_here = 73
 *

Exception up = new Exception("Something is really wrong.");
throw up;  //ha ha

// When I wrote this, only God and I understood what I was doing
// Now, God only knows

// sometimes I believe compiler ignores all my comments

// I dedicate all this code, all my work, to my wife, Darlene,
// who will have to support me and our three children and
// the dog once it gets released into the public.

// drunk, fix later

// Magic. Do not touch.

// I'm sorry.

return 1; # returns 1

10.

Catch (Exception e) {
//who cares?
}

11.

/**
* Always returns true.
*/
public boolean isAvailable() {
return false;
}

12.

/*
* You may think you know what the following code does.
* But you dont. Trust me.
* Fiddle with it, and youll spend many a sleepless
* night cursing the moment you thought youd be clever
* enough to "optimize" the code below.
* Now close this file and go play with something else.
*/

13.

try {
} finally { // should never happen
}

14.

const int TEN=10; // As if the value of 10 will fluctuate...

15.

// This code sucks, you know it and I know it.
// Move on and call me an idiot later.

16.

// If this comment is removed the program will blow up

17.

// I am not responsible of this code.
// They made me write it, against my will.

18.

/* Please work */

19.

// no comments for you
// it was hard to write
// so it should be hard to read

20.

options.BatchSize = 300; //Madness? THIS IS SPARTA!

21.

// If this code works, it was written by Paul DiLascia.
// If not, I don't know who wrote it

22.

// Peter wrote this, nobody knows what it does, don't change it!

23.

/** Logger */
private Logger logger = Logger.getLogger();

24.

// I have to find a better job

25.

// Real programmers don’t comment their code. 
// If it was hard to write, 
// it should be hard to understand.

26.

// This is black magic
// from
// *Some stackoverlow link
// Don’t play with magic, it can BITE.

27.

// For the sins I am about to commit, may James Gosling forgive me

28.

// Comment this later

29.

// Remove this if you wanna be fired

30.

}catch(Exception ex){
// Houston, we have a problem
}

31.

// I can’t divide with zero, so I have to divide with something very similar 
result = number / 0.00000000000001.

32.

int getRandomNumber()
{
Return 4; // chosen by fair dice roll.
// guaranteed to be random.
}

33.

#TODO: Figure out what I’m doing here and comment accordingly.

34.

// If this code is still being used when it stops working, then
// you have my permission to shoot me. Oh, you won't be able
// to - I'll be dead...

35.

// If you are reading this, that means you have been put in charge of my previous project.
// I am sorry, so sorry for you. Godspeed.

36.

// I wrote this while drunk, I don’t know what it does, 
// but if you remove it the program breaks.

37.

// This code worked before, but my cat decided to take a 
// trip across my keyboard...

38.

long long ago; /* in a galaxy far far away */

39.

long john; // silver

40.

#define TRUE FALSE // Happy debugging suckers

41.

// Dear future me. Please forgive me.
// I can't even begin to express how sorry I am.

42.

// private instance variable for storing age
public static int age;

43.

// I am not sure why this works but it fixes the problem.

44.

last = first; /* Biblical reference */

45.

try {
} catch (SQLException ex) {
// Basically, without saying too much, you're screwed. Royally and totally.
} catch(Exception ex)
{
//If you thought you were screwed before, boy have I news for you!!!
}

46.

// John! If you'll svn remove this once more,
// I'll shut you, for God's sake!
// That piece of code is not "something strange"!
// That is THE AUTH VALIDATION.

47.

long time; /* know C */

48.

// Abandon all hope ye who enter beyond this point

49.

/* Ah ah ah! You'll never understand why this one works. */

50.

catch (Ex as Exception) {
// oh crap, we should do something.
}

51.

// TODO make this work

52.

// If you're reading this, then my program is probably a success

53.

// set break point here - you'll never reach it

54.

/*
**    The author disclaims copyright to this source code.
**    In place of a legal notice, here is a blessing:
**
**    May you do good and not evil.
**    May you find forgiveness for yourself and forgive others.
**    May you share freely, never taking more than you give.
*/

55.

// I'm not sure what I did

56.

// This is crap code but it's 3 a.m. and I need to get this working.

References

Best code comments on stackoverflow.com Funniest code comments on quora.com Best comments on loudprogrammer.net Funny code comments on hostingpill.com Funny code comments on blogspot.com

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

开源日报第900期：《weekly》

19 9 月, 2020

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《weekly》
今日推荐英文原文：《iOS 14 resets iPhone’s default apps to Apple’s Safari and Mail after reboot》

今日推荐开源项目：《weekly》传送门：项目链接
推荐理由： Github是本星球最大的程序员社区, 里面不仅有代码, 还有大量的优质文章. Github以仓库为单位对开源项目进行管理, 但github没有提供对单个仓库进行关键词在线搜索的功能(Github对英文搜索支持很棒, 但中文支持差一些). 阮一峰大佬在本项目中推荐了一款名为Sourcegraph的工具,对单个仓库的关键词进行搜索. Sourcegraph是一款好用的仓库搜索工具, 有了它, 我们无需下载仓库到本地, 即可精确定位找到我们所需的信息, 极大提升github的浏览体验~ 同时, 本项目也会每周更新有关技术方面的丰富内容.
今日推荐英文原文：《iOS 14 resets iPhone’s default apps to Apple’s Safari and Mail after reboot》作者：Ian Sherr, Shara Tibken, Stephen Shankland
原文链接：https://www.cnet.com/news/the-iphones-ios-14-resets-default-apps-to-apples-safari-and-mail-after-reboot/
推荐理由：苹果公司最近的新品发布会备受瞩目, 随之而来的是全新的IOS14系统. 但是于此同时, 人们也发现了该系统中存在的重大Bug: 每次重启设备后会自动将默认浏览器设置为苹果自带的Safari浏览器.
iOS 14 resets iPhone’s default apps to Apple’s Safari and Mail after reboot
Users have found a major bug in Apple’s iOS 14 iPhone software. The free software upgrade, which Apple made publicly available Wednesday, includes features many users had long asked for, such as better ways to organize apps, living programs called widgets on the home screen, and the ability to change which default apps the phone uses to browse the web or send an email. That last one doesn’t appear to work.

A growing chorus of Twitter users has been posting about the bug in Apple’s default email and default web browser options. What happens is that whenever they set the default browser to Google’s Chrome, for example, it works as expected, and tapping any link in an app or browser will open Chrome on the iPhone. But then if they restart the phone, iOS 14 changes that default back to Apple’s Safari.

“We are aware of an issue that can impact default email and browser settings in iOS 14 and iPadOS 14. A fix will be available to users in a software update,” Apple said in a statement.

Google and Microsoft didn’t respond to requests for comment. CNET was able to confirm this bug on an iPhone running iOS 14, as was 9to5Mac, which earlier reported the issue.

“We expect whatever issue is happening here will get resolved soon,” another browser maker, DuckDuckGo, said in a statement. Mozilla said it’s working with Apple to resolve the issue for its Firefox browser.

The bug is a reminder that although Apple’s been publicly testing its new iOS 14 and iPadOS 14 software since the since announcing it in the summer, the company’s rarely able to fully iron out bugs before release.

This is partly why CNET’s reviewers recommend backing up your phone to the cloud or to a computer before any upgrade.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第899期：《穷举破解法 cupp》

18 9 月, 2020

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《穷举破解法 cupp》
今日推荐英文原文：《A Day in the Life of a Software Engineer (Quarantine Edition)》

今日推荐开源项目：《穷举破解法 cupp》传送门：项目链接
推荐理由：你身边有经常用一些容易被预测到的密码的人吗？如果你想要劝劝他，就可以考虑看看这个项目——输入可能与密码有关的信息，比如他养的狗的名字之类的，然后让这个项目帮你穷举出他可能用到的密码，没准就能猜到正确答案，这应该足够让那个人提高警惕了。
今日推荐英文原文：《A Day in the Life of a Software Engineer (Quarantine Edition)》作者：Rafay Syed
原文链接：https://medium.com/@rafaysyed/a-day-in-the-life-of-a-software-engineer-quarantine-edition-8054d6ec8f89
推荐理由：作者在家工作的平常一日
A Day in the Life of a Software Engineer (Quarantine Edition)
I always wanted to make one of those “a day in the life of a software engineer” videos, but since the office has been closed since March, I thought I would just write about what life has been like while working from home for over 6 months. If you want to know more about what life has been like for me at the office, check out my previous article here.

I never expected that I would end up working from home for a prolonged period of time in my career. I started working at Salesforce in January 2020, but then the Covid outbreak got worse that the office had to shut down in March. 3 months. That’s how long I was at the office. I thought that this outbreak would slow down and things would start to get better within a few months, but I was wrong. Covid has definitely changed our lives. Some companies have even allowed their employees to work from home forever, such as Twitter! As companies are starting to adjust to this “new normal”, I thought I would talk about how it has affected my work day as a software engineer.

What I like about working from home is that I don’t have to wake up really early in order to think about my commute to work. Atlanta traffic can be one of the worst, so even though my office is only about 25 minutes away from home, it takes me up to an hour just to get there. Instead, I don’t have to think about that anymore. I just need to walk to my desk once I’m ready to work! Now let’s talk about a typical workday from home.
6:45 AM
This is the time that I wake up for one of the early morning prayers. As a Muslim, I pray 5 times a day, so this is the first prayer that happens before sunrise. Once I finish praying, I go back to bed and rest for just a little while longer before I get ready.
8:00 AM
This is the time where I get out of bed, shower, get ready and eat breakfast. I sometimes listen to a mindful reminder in an app called Fabulous when I’m eating breakfast and self-reflect over everything I have in life.

9:00 AM
The first thing I do right before I start working is that I work on a programming challenge that I will spend 15–20 minutes on. I love doing challenges on HackerRank, LeetCode, and Github. I spend no more than 20 minutes working on a problem. The reason why I do this is because it gets my brain wired into work mode and it’s a great warmup before I get into my work tasks. Think about it. Before you work out at the gym, you have to do stretches. I apply this same logic to work.
9:30 AM
I open up my email, calendar and sprint board. A sprint board contains the tasks that I am currently working on. Once I check my email and calendar, I go ahead and start working on the work items on my sprint board. I open up my Pomodoro Timer that way I focus on the task I am working on for 25 minutes and then I give myself a 5 minute break after that.
11:30 AM
By this time, the team will meet up online and we talk about what we worked on the day before, what we plan on working on in the current day and whether we have anything that’s blocking us from completing some of our tasks.
12:00 PM
This is the time I eat lunch nom nom nom ?

1:00 PM
Between 1:00 PM and 5:00 PM, I work on my current tasks by using the Pomodoro timer where I take 5 minute breaks every 25 minutes. Meetings that are scheduled are within this timeframe and the second prayer of the day is also within this timeframe.

Once I finish my work, I put my laptop and work phone away in my backpack and pray the third prayer. The only time I will have my work phone with me is when I need to be on call. You may be wondering why I put my laptop and phone away in my backpack. The reason is because my brain will be out of that work mode. Working from home can get tiring on some days, so it is good practice to put your work items away once you are done for the day. I recommend that you try it if you haven’t already! ?

Once I finish the third prayer, I go to the gym and get my workouts done. I realized that after being in one place all day, I need to go out and get some exercise if I want to be in good health. I alternate my gym days with cardio days, so one day I will go to the gym and do weight training while I will do light cardio the next day such as taking a walk for 45 minutes. The best feeling is coming back home after a workout. It really gives me energy to do more activities in the evening.

When I come back home, I have dinner and then I spend 25 minutes learning a new skill. Once those 25 minutes are up, I take a 5 minute break and then spend another 25 minutes learning another skill or keeping up-to-date with my programming skills.

After my learning sessions are done, I spend at least 10 minutes meditating. Mind training is the most important thing that you can do for yourself. I have been meditating for over one month and it has done wonders for me. It makes me even more grateful for the things I have in life, it relaxes my body and it makes me focus on the present. It also makes me view everything in a positive light. I believe that in order to live a great life, you should include mental fitness as well. As Bob Marley said, “My home is in my head”. If your home is not doing well, how do you expect other things in life to go for you? Always take care of your mind.

Once my meditation session is over, I pray my fourth prayer which is after sunset and keep at least a few hours just to relax and spend time with my wife, play games, watch TV, read a book or write an article. I end the day with the last prayer and get ready to sleep.

Thank you so much for reading and I hope that you stay safe! Follow me on Twitter at retr0rafay.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/