开源日报 - Page 136 of 262

开源日报第500期：《新的开始 getAwayBSG》

28 7 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《新的开始 getAwayBSG》
今日推荐英文原文：《The Future of Code》

我们是不会停下来的（指日报编辑），只要你们不停下来，我们就会在前方等着你们！！！
所以，不要停下来啊（指每天学习）……
今日推荐开源项目：《新的开始 getAwayBSG》传送门：GitHub链接
推荐理由：不管是遇上了什么亦或是没有遇上什么，逃避或是追赶，带来的结果都是相同的——来到一个新的环境。尽管大多数情况下你无法决定你会来到何处，这个项目能够让你在能够选择自己的下一站时提供一个参考，它对比了诸多城市的生活成本和工作机会等等，让你能够从更现实的角度看待你对下一站的各种选择。
今日推荐英文原文：《The Future of Code》作者：DEV.BIZ.OPS
原文链接：https://medium.com/@devbizops/the-future-of-code-14bcd4730d21
推荐理由：兴许以后我们不会需要自己写代码，而是做写代码的指导者
The Future of Code

With computers coding themselves, do humans even matter?
What is the scariest movie you have ever seen? For me, it’s 2001: A Space Odyssey. Maybe it does not have the gore factor or terror including chills, but HAL9000 is right up there with Alien, Predator, and Snakes on a Plane* for most terrifying villain of all-time:
“I’m sorry Dave, I’m afraid I can’t do that”
With every other villain, you are dealing with the irrational. HAL on the other hand is polite, rational, soothing and a 100% certified sinister serial killing computer. What makes HAL even more threatening to us however is the idea of our creations turning the tables us.

We are still well behind an intelligence such as HAL coming into existence. The pace of software development in this decade however may mean we have to reckon with the future sooner than we are prepared for. What happens once we step into the 2020’s?

A few of weeks ago I spoke on a panel called the “Future of Work” at Innovfest Unbound. Most of these talks tend to devolve into debates on whether humanity is going to be made redundant by the advance of machines. Luckily we avoided much of the doom and gloom and discussed more practical considerations of workforce management, upskilling, and the growth in entrepreneurship and freelancing. Underlying all of this change is software.

During the panel I shared how software has enabled greater economic opportunity and career freedom. The Internet and mobile apps have opened up both local and global marketplaces to supplement ones income or transition into entirely new careers. Supplementing these platforms and online gig marketplaces is more content than has ever been available and communities to help level up one’s skills. The digital economy is really the opportunity economy.

This has two implications in the near term. First, there is an even greater need for software developers to meet the growing demand for digital services. Second, with the growing interest in software development as a career, it has never been easier for someone to transition into a software role. Just this past weekend, I spent time with Rails Girls Saigon and watched women with no coding experience launch a fully functioning website in a day.

What does this means for code quality if so many newbies are entering the industry? Very few developers are of the 10X Engineer variety. Most software is written by average developers. So while issues of tech debt and leaky solutions are problematic, the code functions quite fine.

With the growing level of abstractions, the level of complexity of code and knowledge required to write working code has significantly decreased. When I started, I used C primarily and even with libraries, it required writing a lot of low-level code to do basic things like memory allocation. Just getting a server running to deploy an application was a pain. Scripting languages, cloud compute, and CI/CD pipelines have swept away much of that complexity under the rug.

If it has never been easier to write, test, and deploy working code then, couldn’t a computer do the same? That is in fact what one team of AI scientists was able to demonstrate through a process called neural sketch learning:
“It’s basically studied everything on GitHub, and it draws on that to write its own code. A developer can give Bayou a very small amount of information — just a few keywords or prompts, really — and Bayou will try to read the programmer’s mind and predict the program they want.” —— Swarat Chaudhuri, Rice University
You can try Bayou out for yourself. Bayou however is not the only project. Microsoft and University of Cambridge used a similar technique to create DeepCoder which is able to craft small segments of working code. Google has a program called AutoML that writes machine-learning code more efficiently than the code written by the 1,300 people that built AutoML.

The reality of much of the code written these days is plugging things together that already exist with slight modifications. By some estimates, the majority of code in most organizations is open source. Wrapping legacy services with API’s has simplified accessing existing code for new services. Open API’s have vastly extend once complex software tasks and made them available through a single line of code. The plumbing has already been created..

So what exactly are human coders needed for then? Are we leading people into careers in software development that may not even be necessary in a decade?

No, but as in most things during a massive shift in technology, there will be a transition and new opportunities yet to be created. The first thing we need to understand is that the robots are not taking over anytime soon. They are merely accelerating the things we as humans are good at and automating the things that are slow for human minds. We cannot view and analyze thousands of API’s in seconds like AI can. We still need more humans and more creative thinking to guide AI towards problems worth solving:
“If we succeed, we think this can inspire new types of neural nets and make it possible for non-experts to create neural nets tailored to their particular needs, allowing machine learning to have a greater impact to everyone.” —— Google AutoML Team
The second thing is that technology has already automated things that used to take humans days, weeks, and months to do. When was the last time you actually installed a server? We have cloud and automation for that. This is one reason for the rise of startups in the past decade, the tedium and capital costs of getting started has gone to nearly zero:
“The potential for automation that this kind of technology offers could signify an enormous reduction in the amount of effort it takes to develop code.” —— Armando Solar-Lezama, MIT
The third point is that with greater automation comes new opportunities and industries. The idea of being a “software engineer” only emerged in the 1960’s. In the past decade, we have seen the rise of “full-stack engineers”, “data scientists”, and “cloud engineers”. People that build mobile apps was not a thing until 2008. Those apps in turn have created massive economies built to exploit the opportunities and gains in productivity brought about from software.

With any major shift in technology however, it means rethinking the skills that are needed in the next stage. We do not need more “coders” to pump out more lines of code. We need more thinkers and designers and problem solvers. The future of work for developers is turning business problems into logical flows and digital constructs that enable tangible functionality in the most efficient manner. AI is simply the forklift used by human programmers to allow us to handle ever more complex problems.

What do you see as the future of code? How is your organization leveraging technologies like AI to enable developers to be more efficient?
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第499期：《最初的一步 saylovewall》

27 7 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《最初的一步 saylovewall》
今日推荐英文原文：《Should I Quit My Job Today?》

今日推荐开源项目：《最初的一步 saylovewall》传送门：GitHub链接
推荐理由：现在大学高中里都会有个叫表白墙的玩意——简单地说就是匿名表白吧，形式可能有差异但大抵如此。这个项目就是一个表白墙的开源版本，比起用 QQ 空间什么的来弄效果会更好。不过虽然说，表白这种事情，是应该堂堂正正一对一如同骑士对决一样正面交锋的，这是最原始也是最能表示决心的办法，这一点还是不要忘了才好。
今日推荐英文原文：《Should I Quit My Job Today?》作者：Omar Rabbolini
原文链接：https://medium.com/swlh/should-i-quit-my-job-today-ad71a99ce872
推荐理由：工作与乐趣有时难以得兼，舍……这就要自己决定了
Should I Quit My Job Today?

When it is time to call it a day for a dissatisfied engineer
Another day, another feature. Such was the life at this startup I joined in my early years in Hong Kong. Every iteration would bring new requirements for the product, and tight deadlines along with them. We used to work an average of ten hours a day, and leave the office well past 10pm as releases neared. It seemed what we did was never enough, and we were always playing catch up with the latest business requirements.

Yet, I stuck with it, and so did the rest of the engineering team. Why did we put ourselves through such an ordeal?

In my case, it was a combination of factors: I needed a job to keep my visa going, I wanted to prove myself as a manager (and later VP), especially in a new country, and I liked making mobile software. The fact we used bleeding edge technology also helped, and so did the great connection I shared with my team members. We were a big family, and I regret that our eventual acquisition came with a relocation package to the UK which, while great for the rest of them, did not really work for me as I had no intention of moving back West.

I thought about that chapter of my life this past week as a few people I met are struggling with the will to carry on with their job, some because of the delicate situation that Hong Kong is facing at the moment, others more simply because their manager or their company is, or has become, uninspiring for a number of different reasons.

The real question is: does it make sense to stick to a job when you are no longer inspired?
The five pillars of motivation

Photo by Hans Reniers on Unsplash

Motivation to work in a startup or product company really boils down to the following considerations:
- Technology : You are working on something which is innovative, new and exciting
- Product : You are building something unique, and you are doing it well
- Mission : You are solving an important problem, or something you deeply care about
- Culture : You share the same values as the people around you, throughout the organization. You feel you are treated fairly, and there is trust between you and your colleagues, within and outside your team.
These are directly related to the company you work for, and are normally joined by a fifth pillar which is more outward-facing:
- Motivation-By-Proxy : The work you are doing is a proxy to satisfy specific needs in your life, or reach certain goals (e.g. sustaining yourself, prestige, saving money to retire early / starting a family, etc.)
If all five aspects are aligned, congratulations. There is really no reason for you to quit. Maybe you have a better offer somewhere else, but there is no guarantee that all the boxes above will be checked once you move, so you should consider your decision very carefully.

In the majority of cases, one or more aspects are dissatisfactory or misaligned with one’s goals and beliefs. If you are in this situation, you should look at the positive aspects of your job and decide whether they are reason enough to stay. Assuming the problems you are seeing are not coming from within the core of the company, there is a chance that they might be resolved as time goes by.

In fact, this is a good chance for you to be the change that you need in your organization. Working with your peers and your manager should help you see these issues through, either by actually resolving them, or by reframing your perception as you gain a more complete picture of the situation. For instance, a tedious feature set which makes it look like the company has given up on innovation might reveal itself as being in actuality a short-term goal required to win a specific client over.

In any circumstance, it is important to have a good understanding of the actual state of the company and your role before making a decision. Do not be afraid to ask for information and gather as much detail as possible from veritable sources, especially when the issues you are facing come from one of the first three pillars: Technology, Product and Mission.
Timing and tolerance

Photo by NeONBRAND on Unsplash
“The two most powerful warriors are patience and time” — Leo Tolstoy
Tolerance levels vary from person to person. Somebody might be able to live just on Motivation-By-Proxy for years on end, while a more ambitious individual would only put up with, let’s say, an issue with the product roadmap only if it is bound to be resolved within a couple of quarters.

When looking into quitting, it is important to consider whether the issue is temporary or permanent, and whether you can live with it for as long as it persists.

When you are in the thick of things, it is difficult to see the light at the end of the tunnel and instead fall into a pattern of thought that makes whatever issue we are facing seem like a permanent reality. When considering whether to quit in these cases, it is beneficial to delay the decision until the “dark period” is over so that we can take a step back and consider the issue in the right perspective.

Also on the topic of timing, it is important to consider the financial impact of the decision on your life. There is always a risk that whatever endeavor you might partake does not work out as expected. This risk of course varies depending on the nature of your next chapter, for instance quitting to become an entrepreneur is more risky than leaving for a new job which is already lined up, but should nevertheless be taken into account.
The real you

Photo by Rahul Dey on Unsplash
Is it really a success if you are succeeding at what you do not like doing?
The five pillars of motivation we looked at earlier are a framework to help you find the motivation to stick around. They do not deal with your lifetime goals, and they assume the job you are doing fits in your overall life purpose. But what if this is not the case?

You are where you are today undoubtedly because of prior choices in your life. Maybe you decided to study Computer Science because you were good at Math and your parents thought technology was a viable career, but you really liked to play the violin instead. Maybe you have a knack for writing, but never wrote anything beyond technical specs because you thought you are not good enough.

Notwithstanding the commitments you already made in your life, you should never give up on your true passion. Maybe you buried it under a pile of success and achievements, or maybe you locked it away to conform to certain expectations from your family, community and society at large.

Maybe your dissatisfaction with your current job is a subconscious reaction of your true self to the artificial cage you built around it. Maybe it’s time to set yourself free.

Working on your passion does not necessarily require a radical change in your work. You do not need to completely switch overnight and restart your career from scratch.

You can ease into your new career by choosing a freelance or part-time gig related to your present profession to keep the money flowing as you spend more time developing your new skillset.

Alternatively, you can look for a company where you can apply both and make a transition over time. For instance, if music is your thing and you are a software engineer, maybe you can look at companies that produce music software. That might give you the opportunity to network with professional musicians and allow you to either change career, or otherwise express your talents by doing both something you like and something you are good at.
Wrapping up

Photo by Craig Garner on Unsplash

In conclusion, the decision of quitting revolves around whether the time you are investing in your current job is time well spent. In other words, is it aligned with and does it help you achieve your lifetime goals? The moment this is no longer the case, you can safely leave with no regrets. After all, time is a finite commodity.

Also, the people factor is important. Are you working with people you can trust? Is your manager and your organization supportive of your growth? Any misalignment here might affect how quickly you reach your goals, and therefore should be of major consideration in your decision.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第498期：《条条大路通罗马 awesome-roadmaps》

26 7 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《条条大路通罗马 awesome-roadmaps》
今日推荐英文原文：《The KISS of Simplicity》

今日推荐开源项目：《条条大路通罗马 awesome-roadmaps》传送门：GitHub链接
推荐理由：一个关于各种学习路线图的合集。一个职业或者说一个技术方向里包含了各种不同的技术，而路线图就是指导初学者应当学习什么的方向标，尽管多学总不会有错，但是南辕北辙终究还是缺少效率的。路线图的作者们眼界更广，见到的东西更多，借助他们的知识来作为自己下一步的参考自然不是个坏事，如果对接下来要学习什么感到迷茫的话，兴许这些路线图会帮到你。
今日推荐英文原文：《The KISS of Simplicity》作者：Piotr Gaczkowski
原文链接：https://towardsdatascience.com/the-kiss-of-simplicity-b8153a69048e
推荐理由：简单比复杂更容易操纵，尽可能让成果变得简单些
The KISS of Simplicity

Do less but do it better
Imagine a man appearing at a formal ball. He is wearing a perfectly tailored suit, the jacket of which is bright pink with a red checkerboard pattern. His pants are green with purple vertical stripes. The suit is the creation of a renowned designer and it cost quite a bit. The man also has a gold chain around his neck and ruby rings on both hands. Behind him, however, is a woman wearing a black dress and no accessories save for a pair of pearl earrings. Think about the two guests for a moment.

Which of the two would you consider elegant?

The IT industry knows the first type very well. The man in the suit is the equivalent of a system that cost a company millions. The system is made up of several components from different providers that often can’t communicate properly, and more often than not, freeze just at the moment you need to deliver an urgent message to your boss.
Elegance in Tech
Unix philosophy is closer to the lady in the black dress, with a focus on using tools or writing programs that do one thing but do it perfectly.

When we ask Google the definition of “elegance.” it offers two.
1. “the quality of being graceful and stylish in appearance or manner.”
2. “the quality of being pleasingly ingenious and simple; neatness.”
Wikipedia shows something similar with,
“Elegance is beauty that shows unusual effectiveness and simplicity.”
Why am I getting into elegance on a tech blog? Because it is we engineers who are to be blamed for over-complicated systems, a project going over budget, and the general ugliness (better known as “the technical debt”) that surrounds our work. Most of us know the KISS principle, but we often forget about it each time there is a need to implement just one more feature in our code.

Photo by Dan Gold on Unsplash
What Hinders Elegance?
Tight time constraints are the main killers of elegant solutions. Simple does not equal “quick” or “easy.” Usually, it is the opposite. Simple design requires careful thought and analysis of all expected use cases, to come up with an idea that is clear and concise.

While you can build software without a proper design and without putting much thought into the scope of possible functions, maintaining that code will be a pain. Because each time there is a bug, it will most likely be caused by your lack of proper edge-case handling. And without a clear scope of what one function should or shouldn’t do, you’ll most likely end up adding a conditional clause somewhere in the code.

But after ten such cases, your code no longer looks like it did after the initial release. It’s now a soup of obscure conditionals and nobody knows what is the desired behavior of the application. Sometimes a change in something totally unrelated at first sight causes errors in a different subsystem. Everybody then scratches their heads and quietly reverts the last commit. Time for another approach.
Why Complex Is Easier to Implement
Elegant solutions require focus and observation. They require analysis, good communication with the client, and a well-thought scope. If you don’t have time to figure out all the possible input arguments or if you just can’t figure them out because you lack a proper design and the customer is unsure about how he will use the product, you end up skipping a few steps in the process of solving the problem.

But there is also another source of complexity. And this one is much harder to overcome. It’s the abundance of ready-made components and abstractions waiting for you to use. Front-End development is especially vulnerable. Writing an appealing web application using plain HTML5, CSS and Javascript is not an easy task.

That’s why we decide to trust a third-party to implement all the nitty-gritty details so we can focus on the important matters. We choose a framework, look out for a few more modules, and end up with the infamous 3GB node_modules directory. All should be quite alright as long as the abstraction layers in those modules align with our way of using them. More often than not, there is something we can’t agree on with our framework so we end up writing a terrible workaround or a special case just to make it work.

I wish I could share a viable way to deal with leaky abstractions, but I can’t. I don’t have one! But I’m aware we can’t just stop using them. This would be a huge waste of resources.

Photo by John Barkiple on Unsplash
How to Keep it Simple
You write a mobile application? Instead of creating your own backend, use a Backend-as-a-Service such as Firebase.

You want to host a landing page or a blog? Go with a static site generator (like Jekyll or Gatsby) and static file hosting (like Netlify).

You want a CMS with that? Check out Contentful or DatoCMS.

Tired of keeping track of SSL certificates for your web service? Go with an automated refresher like AWS ACM, Traefik, Caddy or Zombie Nginx.

Want your code to run “on demand” instead of paying fixed price of a VPC instance? Try a Function-as-a-Service (or Serverless) solution.

Oh, by the way, unless you have a very refined taste, it’s a good idea to use a managed database service like AWS RDS/Cloud SQL/Azure SQL.

To achieve simplicity is to reduce the number of components instead of accumulating them.
The Benefits of Keeping it Simple
More moving parts often mean more errors. In a classic blog engine example, you can expect at least the following problems:
- Poor database performance.
- Poor blog engine performance (insufficient memory/CPU).
- Insufficient network throughput.
- Disk space running out.
- You overprovision for the most pessimistic use-case thus you overpay the rest of the time.
- Broken deployments.
- Database migration can run wild.
- The VPC may disappear without a trace along with backups.
I’m not here to sell you a protection racket, but if you opt for a static site generator and a static file hosting, most of these problems simply go away. You also gain a free Continuous Delivery pipeline in which each source code change results in changes visible on the page. Both simple and feature-full!
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第497期：《和某海王星没关系 reborn》

25 7 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《和某海王星没关系 reborn》
今日推荐英文原文：《Better Code Reviews》

今日推荐开源项目：《和某海王星没关系 reborn》传送门：GitHub链接
推荐理由：这个作者的仓库里有不少很有意思的书，这个就是其中之一，通过讲述各式各样的在现实生活中并不少见的现象（有时例子就是他自己）来说明一些容易理解的道理。有些道理实际上并不是太复杂，日常生活中每一天都能看见都在无意识的被他影响，这本书能让读者注意到这些没有被重视或者说直接被无视的点。
今日推荐英文原文：《Better Code Reviews》作者：Alex Persian
原文链接：https://medium.com/better-programming/better-code-reviews-190efd53bc10
推荐理由：更好的处理 Pull Request 的方式
Better Code Reviews

Become a more effective and empathetic reviewer
Reviewing code is an daily occurrence for developers. It can be a humbling learning experience, but it can also turn into an egocentric process. Over the last few years I’ve learned some best practices, either through personal experience or excellent advice from peers, that have helped me to become a more effective and empathetic reviewer. I wanted to share some of this information, in the hopes that it will help others. This short post is broken into two main parts: 1. getting the best feedback on your work and 2. providing great reviews for your peers.
Structuring Your PR’s to Make Their Life Easy

@iamdeveloper https://twitter.com/iamdevloper/status/397664295875805184
Avoid massive changelogs
- Keep it small — under 300 lines of changes, if possible.
- If a piece of work requires more than 600 lines try to break it into smaller logical chunks that can be reviewed individually.
- No one wants to be sent a 1000 line PR monstrosity. Good reviewers will often reject a pull request of this scale; they know from experience that they probably won’t be able to to review it effectively.
Structure for comprehension
- Group similar changes into commits. Changing the location of a bunch of files without modifying them? Group that into its own commit, so the reviewer knows it’s not a logical change they need to focus on.
- Commit changes frequently to reduce their scope. For larger pieces of work it is far easier for your reviewer to focus on what’s important when the commits are small.
Short-circuit possible confusion
- If you modify logic or structure that existed in a previous set of commits, ensure you inform the reviewer so they don’t get sidetracked into critiquing now non-existent code. This is applicable for when the reviewer is going through commit by commit.
Provide enough context
- Ensure that your PR is described clearly, whether this is through a linked ticket or a written description in the PR, or preferably both. Provide examples, visual or otherwise, of how your work affects the project. Look at things from the reviewer’s point of view and try to make it as seamless as possible for them to understand the purpose of your pull request.
Approaching a Teammate’s PR Efficiently and Effectively

Review in a timely manner
- Once you are added as a reviewer on a PR, try to review it as soon as possible.
- The maximum time from a request and the first review being completed should never exceed one work day.
Gather context if it’s lacking
- If the PR is lacking context, or a description of its changes, reach out to the writer and get clarification before reviewing. This can significantly reduce back and forth caused by misunderstandings of the code or purpose.
Start at a high level
- Review from the high level down. Hold off on commenting on small changes like style until the larger issues, if they are present, are addressed. This way the author can focus on the most important revisions first. Sometimes the smaller issues will go away along with the larger changes.
- This also cuts down on the possibility of bike-shedding, which detracts from the more important and impactful aspects of the work.
Handling disagreements
- If you disagree with a code block, provide a code example of how you would suggest it be done instead. This is far more useful to the other developer than just leaving a the comment, “this should be different”.
Requesting changes
- Don’t block a PR unless there are fundamental issues with the work. Putting a roadblock in front of your coworker over an argument around naming doesn’t help anyone on the team. Give your teammate the opportunity to address the smaller changes and move on with their tasks without waiting for another round of feedback.
- Small issues should be addressed through a project style guide — but that’s a different topic altogether.
Empathy
- Most importantly, remember there’s another person on the end of your review. Provide feedback in a helpful and constructive way. Always think about how you would want to be given feedback, if it was your pull request that was being reviewed.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/