开源日报 - Page 117 of 262

开源日报第575期：《画质 Anime4K》

11 10 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《画质 Anime4K》
今日推荐英文原文：《Why Doing Your Own Coding Makes You a Better Developer》

今日推荐开源项目：《画质 Anime4K》传送门：GitHub链接
推荐理由：平时看动画，自然想看清楚的，画质更高的；要说到画质，除非需要省流量，不然高的好。而这个项目，乃是一个好算法，帮助提画质。而这个算法，若应用在实际中，就举个例子：video2x（GitHub链接），利用此算法升级，让画质更好。实际的效果，可以参考下面图，差距相当大。其他使用法，如若去探索一番，或有新创意。

今日推荐英文原文：《Why Doing Your Own Coding Makes You a Better Developer》作者：Danny Moerkerke
原文链接：https://medium.com/better-programming/why-coding-your-own-makes-you-a-better-developer-5c53439c5e4a
推荐理由：对于轮子——要想学原理，光是使用不太够，还要自己造。
Why Doing Your Own Coding Makes You a Better Developer

To truly understand the wheel, you need to reinvent it
The other day I interviewed a senior developer position with a JavaScript developer. My colleague, who was also in the interview, asked the interviewee to write a function that would perform an HTTP call and retry it a number of times if it failed.

Since he was writing it on a whiteboard, pseudo-code would have been enough. If he had just demonstrated a good understanding of the matter we would have been happy. But unfortunately, he wasn’t able to come up with a good solution.

Thinking he may have just been nervous, we decided to make it a bit easier and asked him to convert a callback-based function to a Promise-based function.

No luck.

Yes, I could tell he had seen similar code before. He more or less knew how it worked. A solution in pseudo-code that demonstrated he understood the concept would have been fine.

But the code he wrote on the whiteboard made no sense at all. He only had a vague understanding of the concept of a JavaScript Promise and couldn’t explain it well.

You may get away with that if you’re a junior developer, but if you’re applying for a senior position it’s not enough. How would he debug a complex Promise chain and then explain what he did to others?
Developers Take Abstractions For Granted
As developers, we work with abstractions. We abstract code that we would otherwise have to repeat. So when we focus on more important parts, we take the abstractions we work with for granted and just assuming that they work.

Usually, they do, but when things get complicated it pays to really know how these abstractions work.

The candidate for the senior developer position took the promise abstraction for granted. He probably knew how to work with it if he found it in a piece of code somewhere, but he didn’t truly understand the concept and so he wasn’t able to reproduce it in a job interview.

He could have just memorized the code. It’s really not that complicated:
```
return new Promise((resolve, reject) => {
  functionWithCallback((err, result) => {
   return err ? reject(err) : resolve(result);
  });
});
```
I did that. Probably, we all do that. You just memorize a piece of code so you can work with it. You understand more or less how it works.

But if he had truly understood the concept he wouldn’t need to memorize it. He would just know it and have no trouble reproducing it.
Know Your Source
Back in 2012, before front-end framework dominance, jQuery ruled the world and I was reading “Secrets of the JavaScript Ninja” by John Resig(https://www.manning.com/books/secrets-of-the-javascript-ninja), the creator of jQuery.

This book teaches you how to create your own jQuery from scratch, giving you a unique insight into the thought processes behind the creation of this library. Although jQuery has faded into the background over the past years, I highly recommend reading this book.

What struck me the most about the book, was the constant feeling that I could have thought of this myself. The steps as described were so logical and straightforward that I really got the feeling that I could have built jQuery if I had set myself to it.

Of course, in reality, I would never be able to do that — it is far too complicated. My solutions would be too simple and naive to work and I would just give up. I would just take jQuery for granted and trust it to work. After that I would probably not take the time to figure out how it works. I would just use it as a black box.

But reading this book changed me. I started reading source code and found out that many implementations of solutions were pretty straightforward, even obvious.

Now, coming up with these solutions yourself is of course an entirely different thing. But reading source code and reimplementing existing solutions yourself is exactly what helps you come up with your own.

The inspiration you get and patterns you discover will change you as a developer. You will find that this great library you use and think of as magic is really not magical, but just a simple and smart solution.

You may take time understanding code, step by step, but it will also make you go through the same small, incremental steps the authors took to create it. This gives you more insight into the process of coding and more confidence to code your own solutions.

When I started using JavaScript Promises I thought they were magic. Then I learned they’re just based on callbacks and my vision of programming was changed forever.

This pattern that was meant to get rid of callbacks was implemented using… callbacks?

This changed me. It made me realize that these are not incredibly complex pieces of code that were far too complicated for me to understand. They are patterns that I could easily understand if I had the curiosity and will to dive into them.

That’s how you really learn how to program. That’s how you become a better developer.
Reinvent That Wheel
So go ahead and reinvent that wheel. Code your own data binding, code your own Promise or even your own state management solution.

It doesn’t matter if no one will ever use it. You will have learned. And if you could use it in one of your own projects, that would already be great. You’ll develop it further and learn even more.

The point is not to use your solution in production but to learn. Coding your own implementation of an existing solution is a great way to learn from the best.

It’s how you become a better developer.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第574期：《我当即写了两句诗 Chinese_poem_generator》

10 10 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《我当即写了两句诗 Chinese_poem_generator》
今日推荐英文原文：《How Much Documentation Do You Really Need?》

今日推荐开源项目：《我当即写了两句诗 Chinese_poem_generator》传送门：GitHub链接
推荐理由：有的时候我们需要一些藏头诗或者别的什么诗词，但是自己又没读过诗，这个项目就可以让你临时写一首诗了。通过诗词数据训练好一个模型之后，就可以让它来写一首看起来还挺像样的藏头诗了。不过尽管机器写出来的诗还有模有样，但是看过原理之后就会发现这并非是一种创意，而是对那些诗词进行模仿的成果——所以说你完全可以尝试着自己动手，兴许你的创意能弥补不足的知识量也说不定。
今日推荐英文原文：《How Much Documentation Do You Really Need?》作者：Aphinya Dechalert
原文链接：https://medium.com/better-programming/how-much-documentation-do-you-really-need-c7ccda9ab5f2
推荐理由：文档虽好，可不要贪多哦
How Much Documentation Do You Really Need?

When too much or too little becomes your Achilles heel
Documentation is often bundled into a statement of work (SoW) and becomes a necessary document that sits in with a contract. They are often produced by analysts, who consult with stakeholders and then often define with meticulous detail what the requirements, exact tasks, needs, and everything else in between are.

At first, it seems logical to have such a document, mostly for verification and legal purposes. However, on a software development level, this methodology of documenting everything in such granular detail embeds the monolithic method of implementing a waterfall workflow.

This creates a rigid approach to software development that doesn’t give much room to respond to change or to enable developers to rapidly prototype a solution.

Requirements are often also one-sided and unvalidated, leaving the business more vulnerable to bigger failures — not because the developers haven’t delivered, but rather because the intended audience didn’t respond as expected to the software.
The Diminishing Returns of Over-Documentation
The more documentation you begin with, the more diminishing returns you are receiving in actual value. This is because the time it took to write the documentation prior to any development work is a sunk cost. There is nothing produced from it yet, nor is there any guarantee that the project will ever commence, either.

The more documentation there is, the more time, resources, and money it takes away from other endeavors. The opportunity cost increases as the document becomes more detailed, reducing the business’s ability to be truly agile and to pivot to customer and market demands.

This is because the custom software is a solution based on pre-defined requirements, rather than one that is reflective of reality and true business needs.

Discovery of needs often comes during the development phase, and extensive documentation locks the business in on a contractual and financial level for something that may not end up being relevant.
When There Isn’t Any Document at All
For many businesses, especially those new to an agile approach to software development, the issue of finding the right balance of documentation can be a complicated task.

However, there is a difference between not having any documentation versus indecision. If the business is clear with their values, goals and expected outcomes on a strategic scale, developers are able to produce prototyped solutions quickly. This allows the business to acid-test the investment against a consumer group.

When the business doesn’t have any documentation or a clear idea of what they’re looking for on a strategic level, it’s harder for developers to discern business rules required for the system. This often results in delays and a potentially flaky system because the business is unclear about what it wants, and therefore, developers cannot deliver a solution that is geared towards a specified problem.

The issue here is not due to the lack of documentation, but rather that the business is unable to communicate their needs and wants. This can be crippling to the software development process and poses a threat to delivery velocity — despite being on the opposite spectrum for documentation.

This is because documentation not written by developers is more a tool to clearly capture the wants and needs of the business, not to dictate to developers what they should be doing.
Balanced Approach with Living Documents
The idea of having living documents means that all parties involved in the software development process contribute to the externalization of knowledge.

They are written by each group for a particular audience and is called a living document because of its activity. The initial documentation for the entire project creates an ideological scaffold for the software to fulfill. It is not prescriptive, nor is it overly descriptive. The living document aims to capture parts of knowledge that are not immediately obvious in the code.

This means that for certain audiences, more documentation will be required than others, and is based on relevancy only. For example, the business analyst is only expected to capture required business rules for backend developers to translate. Backend developers are expected to document their translations for their consumers, such as API documentation for frontend developers.

There is no single person or group that creates or maintains the process of documentation in isolation. When this happens, over-documentation in certain areas will often occur.

The best approach to documentation is to distribute the workload among different groups and only to document what is actually necessary. This will put less risk of falling into a waterfall method, while maintaining clarity for the business and their developers.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第573期：《汤里有毒 nows》

9 10 月, 2019
开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《汤里有毒 nows》
今日推荐英文原文：《11 rules of effective programming》

今日推荐开源项目：《汤里有毒 nows》传送门：GitHub链接
推荐理由：心灵鸡汤，指的是能够为人的思想提供所谓正能量的文字片段；而反过来派生出的毒鸡汤，则是提供负能量的。这个项目提供了一个畅饮毒鸡汤的地方，简单粗暴的界面可以很方便的分享给朋友，有福同享有难同当嘛。不过这也就图一乐看看就算了，不管是心灵鸡汤还是毒鸡汤，在每个人眼里可能都有不同的感受，它们没有对错正负之分，而你的想法也不应到受这些影响，而是应该由自己决定。
今日推荐英文原文：《11 rules of effective programming》作者：Jakub Kapuscik
原文链接：https://medium.com/swlh/11-rules-of-effective-programming-8932f2d99711
推荐理由：让你花掉的时间带来更高收益的小技巧
11 rules of effective programming

This is by no mean an exhaustive list but rather my subjective top after spending several years in IT. Hope you finds some of those helpful

1. The Boy Scout Rule
“Always leave the campground cleaner than you found it” -that’s a great rule to live by. When you are near campground you should make it cleaner even if it was not you that made the mess. That’s one of the rule of scouts. Just the same should apply to programming. As Robert C. Martin paraphrased it “Leave your code better than you found it”. If we find some hard to read piece of application that someone else wrote and we spent some time understand, let’s make it at least a bit better. If it is out of the scope of task we are working on, one can always create new small technical task, describe it well and take it to the next sprint.

Minimalist version of this rule would be more like a sing in public toilets. We should at least not worsen the condition it is in. We have to remember that some people will one day take over that piece of application we developed and will try to modify it. Let’s just not make their life harder.
2. Think about problem, not only solution
Software developers are really great in implementing solutions. We know languages, patterns, libraries, frameworks and understand how to use them. The problem is that often things we are doing make no sense from business perspective. Some features you are developing may be duplication of existing ones that business owner did not know about. Some may not be well-considered and will never make it to next release or simply no user will ever use them. That is a huge wast of time, money and source of frustration. A lot of people do not bother to ask developers on their opinions and just assumes that their job is to deliver the feature. No deliberation. Only technical work.

Developers are the ones working with the application every single day. They know every feature even if nobody used it. Sometimes task that seems to be easy from business perspective takes months of development. Some that seems nearly impossible take days. The reason is lack of communication between the people that will be implementing a feature and ones that request it. There is a huge difference between those two:
1. Create persistent storage for users’ shopping carts
2. Users should be able to save their shopping carts and use it on mobile and web application
The first one is straightforward. No questions asked. The second one is a bit harder as it makes you think about the reasoning and you will be the one proposing solution to a given problem. There will be a lot of questions about details, functional requirements, quality attributes and others. The solution will be much better worked out as now you are not just an executor.
3. Think about Total Cost of Ownership
It is very tempting to sometimes cut corners, skip tests for later, leave temporary solution and promise to correct it later. In most cases you never will if it won’t break. There will be new task, priorities, features to implement and issues to fix. The problem you will have will be that such piece of application probably will break. Moreover, it will be very hard to fix.

Total Cost of Ownership of a feature is a sum of money and effort spent from start of development, through deployment and maintenance, all the way to termination. If we take shortcuts during development it will be the cheapest part of all. You may release faster but maintenance will be terrible, users will be unhappy and in total everything will be more expensive then it should.
It is always better to do it right the first time

4. Use SOLID
There are a lot of great rules in form of acronyms in programming: DRY, KISS, YAGNI, SOLID and much more. SOLID is a set of rules that should help make code cleaner and avoid common traps.

It can be a great checklist for your code before pushing it to repository. Does this class support Single Responsibility Principle? Can this class be substituted by any other from same hierarchy (is LSP fulfilled)? It will help filter out a lot of sources of future problems. Understanding and conscious application of reasons behind each rule will make you better programmer and increase quality of your code reviews.
5. Use Design Patterns
In most cases you are not the first one trying to solve a problem you are facing or implement a feature with similar requirements. There have been thousands of CRM, CMS, banking systems, chats, online shops, marketplaces and basically any possible type of application one can think of. System you are developing may be the best on the market or have some extremely advanced and unique features nobody else have. Still, most of the job will be at some degree referential. Someone else might try to do it on number of different ways and even describe the whole process. It may save you a lot of hassle and guide to better solution.

There is a great book by the Gang of Four presenting some of repeatable patterns that could be used to tackle common problem. It was wrote in 1994 but those are still valid and helpful. In software those are ancient times but somehow problems we are facing writing code are now not much different. There have been a lot of more newer design patterns developed since then. Knowing them can make your job much easier.
All design is redesing. Learn from the experience of others

6. Minimize complexity
Software development is a complex task by it’s nature. Do not make it more complicated then necessary. It is sometimes very tempting to implement some business rules by introducing few extra ‘ifs’ or loops in a function. Development will be faster but code will get darker and adding new features will just make it more complex. If something will go wrong it will simply be harder to find out the reason.

There is a great and very simple metric with a cryptic name Cyclomatic Complexity. It’s was introduced in 70s but can still be very useful. This metric measures number of way your code can be executed. Each conditional statement and loop adds +1 to the score. The smaller the score the better. When we are analyzing a method and the score is in range:
- 0–10: code is well structured and should not cause unexpected problems
- 10–20: code is quite complex and has a lot of potential paths of execution to test. Candidate for refactoring
- 20–50: code is utterly complex and should be subject to refactoring
- 50+: refactoring is a must
```
# CYC = 1 
def cycle(name, bike, view_points=[]):
    if len(view_points): # +1
        if name and bike: # +2
            for point in view_points: # +1
                print("{} is going on his bike {} to {}".format(name, bike, point))
    else:
        print("No places to go. Sorry")

# CYC = 5
```
Readability is more important then performance. There are some limitation to this statement but basically readability pays of in a long term. You are able to change your code with less bugs. Micro-optimization may easily make your code a mess and do not bring much value to users.
7. Don’t do it alone
It may sound counter intuitive but programming is a social activity. Age of programmers hidden in darkness of a basement is over. Sharing expertise and experiences is getting more and more important. In the worst case scenario people you are talking to will become your rubber duck but most likely you will receive some valuable feedback. Someone may identify problems in your solution you did not even consider. Taking a look from different perspective is a great tool and is very easily available.

No single person should be responsible for a deployed piece of code. It is a job for a team, not a person, to deliver new features. Code review, pair programming, pull requests are tools that take responsibility from a person and moves it to a group of people with preferably cross-functional skills. Responsibility for an important feature that may influence performance of whole company for better or worse is simply too much to shoulder for a developer. Such situation is very unhealthy and should never take place.
8. Tests are a must
Finding bugs early is extremely important and saves lot of effort and angry calls from clients. Discovering problems early makes them easier to solve. We are able to remember all details and logic behind specific piece of application best when we are developing it. We remember all reasoning for making specific decision and how to debug each piece of application. Cost of fixing bugs grow exponentially over time.

Source: https://deepsource.io/blog/exponential-cost-of-fixing-bugs/
9. Learn English
Sharing knowledge have always been one of fundamentals of software community. Most of the information is written in English and is easily accessible. It it right now most popular language of all in software world. If you are not able to read and write in English you will have much harder time and loose a lot of opportunities. Moreover, syntax of nearly every language is by default written in English.

It is also a good practice to write comments and names in code in English. It makes code cleaner and more consistent with the syntax. If we are sharing code with other people, especially from different country, there is basically no better way then to do it in English.
10. Multitasking makes you stupid
People are simply not able to make multiple things at once well. Software development requires using abstract concept and often building quite complex mental models. If you get distracted or start working on something else you lost it all and have to start from the beginning. Moreover, there are multiple studies that proved that multitasking has negative impact on performance, productivity and IQ.

Source: https://insights.sei.cmu.edu/devops/2015/03/addressing-the-detrimental-effects-of-context-switching-with-devops.html

I have once been on a training in a software house that introduced very useful practice. If you do not have any scheduled meetings or calls you are free to play “Tomato”. The rules are very simple -you do not have to speak to anyone. If someone ask you any question, you answer with a single word: “tomato”. Therefore, you show that you are in a middle of work and do not want to be bothered. When people are in ‘tomato mode’ they also indicate it in their calendars for chosen hours. It is not always good to go fully “tomato” but it is interesting way of improving performance.
11. Better less, but better
The less code and infrastructure to maintain the better. There are a lot of people that like to boast about huge number of line of code in their application, number of modules, servers, nodes, pods, micro-services or any other things. There is a chance that every line of code in their application is of highest quality and is just in the right place. But this is a very rare case. If you can do the same job with usage of fewer resources you should go for it. Quality is a the goal, not quantity.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/
开源日报第572期：《领队 leadership》

8 10 月, 2019

开源日报每天推荐一个 GitHub 优质开源项目和一篇精选英文科技或编程文章原文，坚持阅读《开源日报》，保持每日学习的好习惯。
今日推荐开源项目：《领队 leadership》
今日推荐英文原文：《In Code We Trust》

今日推荐开源项目：《领队 leadership》传送门：GitHub链接
推荐理由：技术领导，每个项目团队中都存在的角色。他们需要对技术有足够的了解，但是更多的时候并不是在写代码——而是管理团队。这个项目是一家公司内开放阅读的技术领导指南，如果你刚好担当了这个重任的话，从前人的经验教训中获取足够多的知识就显得十分重要，作为团队的引路人，你必须要负起责任带大家走向胜利，虽然这可能是一条注定不平坦的道路，但是你会得到更多平常难以得到的经验。
今日推荐英文原文：《In Code We Trust》作者：Ryan Nehring
原文链接：https://medium.com/better-programming/in-code-we-trust-c6eee2cd1600
推荐理由：用户给予开发者信任，开发者自然应当回应这份期待
In Code We Trust

Test more, it matters
Despite our best efforts, we programmers remain imperfect beings. Time constraints, misunderstood problem sets, limited testing, and technology conflicts all contribute to mistakes in the applications we build.

In the best cases, these mistakes manifest as minor annoyances to the user. In more severe cases, they can render our programs unusable. In either of these cases, the problem is visible and readily apparent and can be corrected through revision.

There is a much more dangerous type of mistake, however, with the potential to cause severe harm under certain conditions; the systemic failure.

Systemic failures in code are mistakes made in the logic or algorithm of the application. These mistakes happen silently and produce outputs that are incorrect but present as accurate.

Users trust our systems. When they click a button to find out their profit for a month in their accounting software, they expect and trust that the result is correct.

A mistake in that calculation could be disastrous to a small business owner. They may take on more inventory or pay a bill early with the mistaken belief that they have more cash on hand than they do.

In an even more extreme example, consider the software that runs inside of hospitals. We are programmers, not health care professionals, so our inherent understanding of the variables at play is limited. That’s incredibly dangerous.

Seemingly minor code mistakes, like mixing up a user ID or having a database transaction fail, could result in a patient getting the wrong medication, the wrong treatment, or being fed something they’re allergic to. It’s not too hyperbolic to say that lives are literally on the line.
Trust but Verify
As programmers, we have a responsibility to ensure our code functions as advertised. Far too often, if our code compiles or executes and produces output, we assume it’s correct.

If nothing blinks or beeps or flashes, then we’re satisfied that we’ve solved the problem.

I suspect this stems from our logical natures. We tend to have faith in the logical parts of the systems we build, and consider the UI and connecting threads to be little more than the supporting cast, so we rarely double-check that logic.

We must verify that all the parts of the applications we build are functioning correctly, not just the parts we see.
Testing
Testing is an integral part of the development process and one that is short-changed far too often. Time spent testing should be commensurate with the complexity of the program you’re building, and expand from there, depending on the stakes at hand.

It’s probably not worth spending three months testing your form processor script to ensure no one ever enters a bad email address, but if your program has to calculate insulin dosages you better keep testing until you’re absolutely sure it’s correct.

I don’t just mean running the program over and over either. When the calculations are critically important, I frequently revert to pen and paper and run some numbers by hand to be positive I have the formula perfect.
Be Trustworthy
Ultimately, users are going to trust your applications in most cases. It’s in our nature and software has become so ubiquitous to daily life that most people rarely give its accuracy a second thought.

It is incumbent upon us as programmers to be worthy of that trust, especially in instances where the results have real-world consequences, and that means — testing.

Lots and lots of, often mind-numbing, repetitive testing.

Be diligent and mindful in your process and your projects will benefit from it, in all cases. Form these habits now and you’ll enjoy the added benefit of fewer refactors and code revisions, as well as happier users who love your application.
下载开源日报APP：https://opensourcedaily.org/2579/
加入我们：https://opensourcedaily.org/about/join/
关注我们：https://opensourcedaily.org/about/love/