The New Year's List of the Father of Keras, You Deserve It in 2019

Things to note during development

• Code isn't just meant to be executed. Code is also a means of communication across a team, a way to describe to others the solution to a problem. Readable code is not a nice-to-have, it is a fundamental part of what writing code is about. This involves factoring code clearly, picking self-explanatory variable names, and inserting comments to describe anything that's implicit. The code you write isn't just for you to run. Code is also a way to communicate across teams, a way to describe a solution to a problem to colleagues and users.Readable code is not a "nice to have, but okay to not have" thing, but one of the most important parts of writing code. Ensuring that your code is readable involves breaking it down cleanly, choosing good, self-explanatory variable names, and describing any implicit content by adding comments.
• Ask not what your pull request can do for your next promotion, ask what your pull request can do for your users and your community. Avoid “conspicuous contribution” at all cost. Let no feature be added if it isn't clearly helping with the purpose of your product. Don’t just think about how your pull request can help you get your next career promotion.Think about what you can bring to your users and community.If a feature doesn’t clearly contribute to achieving the purpose of the product, don’t add it.
  
• Taste applies to code, too. Taste is a constraint-satisfaction process regularized by a desire for simplicity. Keep a bias toward simplicity. Keep it simple.
• It's okay to say no — just because someone asks for a feature doesn't mean you should do it. Every feature has a cost that goes beyond the initial implementation: maintenance cost, documentation cost, and cognitive cost for your users. Always ask: Should we really do this? Often, the answer is simply no. Learn to say no. Just because someone asks you to do a feature doesn’t mean you should do it. Developing each feature requires a certain amount of cost: maintenance cost, documentation cost, and user cognition cost. Always ask yourself questions like:Should we really do this? The answer is usually no.
  
• When you say yes to a request for supporting a new use case, remember that literally adding what the user requested is often not the optimal choice. Users are focused on their own specific use case, and you must counter this with a holistic and principled vision of the whole project. Often, the right answer is to extend an existing feature. When you're ready to agree to support a new use case, be aware that adding a user requirement that appears to be satisfied is usually not the best approach. Users are focused on their own specific use cases, and you must consider the overall vision of the product from the perspective of the entire project.Usually, the right approach is to expand upon existing features;
• Invest in continuous integration and aim for full unit test coverage. Make sure you are in an environment where you can code with confidence; if that isn't the case, start by focusing on building the right infrastructure.Invest in continuous integration with the goal of achieving complete unit test coverage.Make sure you are in an environment where you can write code with confidence; if not, you need to build the right infrastructure first.

• It's okay not to plan everything in advance. Try things and see how they turn out. Revert incorrect choices early. Make sure you create an environment where that is possible. It’s not necessary to plan everything in advance.Test it first and see how it works.This will help you avoid making the wrong choice early on. Of course, you must first ensure that you have created an easy-to-use, stable and comprehensive development environment.

• Good software makes hard things easy. Just because a problem looks difficult at first doesn't mean the solution will have to be complex or hard to use. Too often, engineers go with reflex solutions that introduce undesirable complexity (Let's use ML! Let's build an app! Let's add blockchain!) in situations where a far easier, though maybe less obvious, alternative is available. Before you write any code, make sure your solution of choice cannot be made any simpler. Approach everything from first principles. Good software makes difficult things easy. Just because a problem is difficult at first glance doesn’t mean the solution has to be complex or difficult to use. In many cases, engineers will habitually come up with very complex solutions when there is actually a simpler and easier solution that may not be so obvious.Before you write any code, make sure the solution you choose is the simplest one.
• Avoid implicit rules. Implicit rules that you find yourself developing should always be made explicit and shared with others or automated. Whenever you find yourself coming up with a recurring, quasi-algorithmic workflow, you should seek to formalize it into a documented process, so that other team members will benefit from the experience. In addition, you should seek to automate in software any part of such a workflow that can be automated (eg, correctness checks). Avoid implicit rules. Make any implicit rules you have formed explicit and share them with others, orMake it automaticWhen you find yourself coming up with a recurring, quasi-algorithmic workflow, you should look for ways to standardize and document the process so that other team members can benefit from it. In addition, for workflows that can be automated, you should automate them as much as possible in your software.
• The total impact of your choices should be taken into account in the design process, not just the bits you want to focus on — such as revenue or growth. Beyond the metrics you are monitoring, what total impact does your software have on its users, on the world? Are there undesirable side effects that outweigh the value proposition? What can you do to address them while preserving the software's usefulness? When designing, consider the overall impact of your choice, not just revenue or growth. In addition to the metrics you’re already monitoring, what impact will the software have on users and the world at large? Are there any undesirable side effects? What can you do to address these issues while ensuring software availability?

How to write a better API?

• Your API has users, thus it has a user experience. In every decision you make, always keep the user in mind. Have empathy for your users, whether they are beginners or experienced developers. Your API has users, so it also involves user experience.In every decision you make, consider the user. Think from the user's perspective, whether the user is a newbie or an experienced developer.
• Always seek to minimize the cognitive load imposed on your users in the course of using your API. Automate what can be automated, minimize the actions and choices needed from the user, don't expose options that are unimportant, design simple and consistent workflows that reflect simple and consistent mental models. Try to reduce the cognitive load on users when using the product API. Automate all steps that can be automated.Minimize the number of actions and choices that users need to make, don’t display unimportant options, and design simple, consistent workflows that reflect simple, consistent mental models.
• Simple things should be simple, complex things should be possible. Don't increase the cognitive load of common use cases for the sake of niche use cases, even minimally. Simple things should be dealt with simply, and complex things should be simplified as much as possible.Don't increase the cognitive load of common use cases just for a few special use cases.

• If the cognitive load of a workflow is sufficiently low, it should be possible for a user to go through it from memory (without looking up a tutorial or documentation) after having done it once or twice. If aThe cognitive threshold of workflow is low enough, then users can complete the operation by feeling and memory after using it once or twice, andNo need to look for tutorial documentation.

• Seek to have an API that matches the mental models of domain experts and practitioners. Someone who has domain experience, but no experience with your API, should be able to intuitively understand your API using minimal documentation, mostly just by looking at a couple of code examples and seeing what objects are available and what their signatures are.Strive to make APIs that match the mental models of domain experts and practitioners.Someone with domain experience but who has not used your API should be able to intuitively understand your API with minimal documentation, such as usually being able to get a good understanding of your API just by looking at some code examples and seeing what objects are available and what their characteristics are.
• The meaning of an argument should be understandable without having any context about the underlying implementation. Arguments that have to be specified by users should relate to the mental models that the users have about the problem, not to implementation details in your code. An API is all about the problem it solves, not about how the software works in the background. The meaning of a parameter should be easy to understand without requiring any background information about the underlying implementation. Parameters that must be specified by the user should be related to the user's model of the problem, not to implementation details in the code. The core of an API lies in the problem it solves, which has nothing to do with the software's workflow behind the scenes.
• The most powerful mental models are modular and hierarchical: simple at a high level, yet precise as you need to go into details. In the same way, a good API is modular and hierarchical: easy to approach, yet expressive. There is a balance to strike between having complex signatures on fewer objects, and having more objects with simpler signatures. A good API has a reasonable number of objects, with reasonably simple signatures. The most powerful models are modular and hierarchical: simple at a high level, yet precise in detail.A good API should also be modular and hierarchical: easy to use and expressiveA good API has a reasonable number of objects with simple features.
• Your API is inevitably a reflection of your implementation choices, in particular your choice of data structures. To achieve an intuitive API, you must choose data structures that naturally fit the domain at hand — that match the mental models of domain experts. Your API is a reflection of your implementation choices, especially your choice of data structures. To implement an intuitive API,You have to choose a data structure that is appropriate for the domain in question, i.e. one that matches the model of the domain experts.

• Deliberately design end-to-end workflows, not a set of atomic features. Most developers approach API design by asking: What capabilities should be available? Let's have configuration options for them. Instead, ask: What are the use cases for this tool? For each use case, what is the optimal sequence of user actions? What's the easiest API that could support this workflow? Atomic options in your API should answer a clear need that arises in a high-level workflow — they should not be added “because someone might need it.”Intentionally design for end-to-end workflows rather than a set of atomic features.Most developers ask when designing an API: What features should be provided? Let's provide configuration options for these features. In fact, the correct question for developers should be: What are the use cases of this tool? For each use case, what is the best sequence of operations for users? What is the simplest API that can support this workflow?
• Error messages, and in general any feedback provided to a user in the course of interacting with your API, is part of the API. Interactivity and feedback are integral to the user experience. Design your API's error messages deliberately.Error reporting and any feedback provided to users during their interaction with the API are part of the API.Interactivity and feedback are an integral part of the user experience. You need to design your API's error messages carefully.
• Because code is communication, naming matters — whether naming a project or a variable. Names reflect how you think about a problem. Avoid overly generic names (x, variable, parameter), avoid OverlyLongAndSpecificNamingPatterns, avoid terms that can create unnecessary friction (master, slave), and make sure you are consistent in your naming choices. Naming consistency means both internal naming consistency (don't call “dim” what is called “axis” in other places) and consistency with established conventions for the problem domain. Before settling on a name, make sure to look up existing names used by domain experts (or other APIs). Because code is communication, naming is important, whether you are naming a project or naming a variable. The name reflects the way you think about a problem.Avoid using overly generic names, avoid using overly lengthy naming patterns, avoid using terms that could cause unnecessary misunderstandings, and make sure you are consistent in your naming choices.Naming consistency means both internal naming consistency and consistency with established norms for the field the problem is in. Before settling on a name, make sure to look for names that are already being used by experts in the field.
• Documentation is central to the user experience of your API. It is not an add-on. Invest in high-quality documentation; you will see higher returns than investing in more features. Documentation is key to the user experience of your API. It is not an add-on.Invest energy in writing high-quality documentation.This can bring higher returns than developing more features.

• Show, don't tell: Your documentation should not talk about how the software works, it should show how to use it. Show code examples for end-to-end workflows; show code examples for each and every common use case and key feature of your API. Show users instead of telling them: Your documentation should not discuss how the software works, but should show users how to use it.Code examples showing end-to-end workflows;Show code examples for each common use case and key feature of your API.
  

  If there is an exam on Keras, I have prepared a cheat sheet

Super Neuropedia

word

univariate

 [ju:nɪ'veərɪrt] adj. univariate

multivariate

 [mʌltɪ'veərɪɪt] adj. multivariate

phrase

logistic regression  Logistic Regression

service implementation  Service Implementation