> 2021年11月19日信息消化 ### Daily Coding Problem: Problem #260 [Medium] This problem was asked by Pinterest. The sequence `[0, 1, ..., N]` has been jumbled, and the only clue you have for its order is an array representing whether each number is larger or smaller than the last. Given this information, reconstruct an array that is consistent with it. For example, given `[None, +, +, -, +]`, you could return `[1, 2, 3, 0, 4]`. ```python def deduce_nums(arr): ln = len(arr) count_gt = sum([1 for x in arr if x == '+']) first = ln - count_gt - 1 nums = [first] small, large = first - 1, first + 1 for sym in arr[1:]: if sym == '+': nums.append(large) large += 1 else: nums.append(small) small -= 1 return nums # Tests assert deduce_nums([None, '+', '+', '-', '+']) == [1, 2, 3, 0, 4] ``` ### Principles for Designing Successful Web APIs [#64 - Principles for Designing Successful Web APIs - James Higginbotham](https://techleadjournal.dev/episodes/64/) #### Principles of Web API Design Book - [Keith Casey] always said that API design represents the effort, required design of the third user interface, or we referred to an API design as the third user interface. It’s the UI for developers. API 设计代表了第三个用户界面的努力、所需的设计，或者我们将 API 设计称为第三个用户界面。这是开发人员的用户界面。 - API design centers on effective communication. And it’s not just communication between developers, but it’s communication that combines product thinking, business, and technology all in one. API 设计以有效沟通为中心。这不仅仅是开发人员之间的交流，而是将产品思维、业务和技术融为一体的交流。 #### Importance of Designing API Properly - I think it really goes to communication. We don’t oftentimes think of our API design as part of the communication effort. We think of the documentation, the web portals, developer portals, marketing materials and other things. But our design itself communicates. The words that we choose, the patterns that we apply, they all communicate to us. #### ADDR Process Align → Define → Design → Rework - If we align, first and foremost, to make sure that all of our assumptions are dealt with, that we’re not writing code that has assumptions built in that are incorrect. We’re not designing an API likewise that has incorrect assumptions. We understand what the needs are, what the outcomes are. We break those down to the next level and understand step by step what we need to do. Then the API design will evolve along with it. - And then we apply one or more **API styles** to Design the API. So we might apply a REST approach for the majority of our operations. Maybe offer a GraphQL. All using the output of the Define phase. An API profile that defines what the API is supposed to do at a high level. Protocol agnostic. - And then once we’ve designed it, now we have this high level design that we can quickly push into an **OpenAPI Spec**, or **GraphQL SDL** (Schema Definition Language) or a **gRPC IDL** (Interface Definition Language), we can capture it and then socialize it. - We can generate **mock implementations** of our API using tools that can take in one of those definitions and create like an **in-memory mock** implementation of it. Just so that you can kind of try it out without it really being completely coded up yet. #### API Boundaries and DDD - Encourage **EventStorming** during the Align phase to try to surface things. If it’s a domain that’s a little bit newer for some people, bringing in subject matter experts from the domain, and having collaborative sessions to explore and understand it, is really valuable. - Unless you just really surround all of that really large API with a lot of copious documentation that guides the reader to where they need to be. Unless you do that, then it’s really hard to get started, and it’s really not approachable to have to take on an API that’s really large. - The idea is to bring in boundaries where we can segment parts of the API. That doesn’t necessarily mean that you have more than one API product. It means that you’re finding different APIs or different operations that are cohesive. - So I go back to the fundamentals of software development: High cohesion, loose coupling. - Loose coupling says we don’t want to tie into the internals of our systems, into the implementation, very much like encapsulation. We want to hide the internal details from the external API. We want to loosely couple and just coupled to the API itself, not to the internal implementation details. 松散耦合表示我们不想绑定到我们系统的内部和实现中，就像封装一样。我们想对外部 API 隐藏内部细节。我们希望松散耦合并且只耦合到 API 本身，而不是内部实现细节。 - High cohesion is about having related functionality grouped together in the same code base, rather than scattered all over the code base, where it’s hopping between module to module where things are just all over the place. 高内聚性是将相关的功能组合在同一个代码库中，而不是分散在整个代码库中，在模块之间跳来跳去，到处都是。 - Taking the time to evaluate where those boundaries are for your APIs will enable you to be more efficient and decompose a very largely scoped product or surface area of API operations into smaller bounded areas that are more digestible and easier to manage, and easier to decompose for delivery by the API providers. - We use EventStorming as a great way to find that we can lay out a particular process, start with our events and then start to expand and find the commands that generate those events, and then identify aggregates, and detail out the event storming process. Oftentimes, those aggregates are really good hints of where API boundaries are at. 我们使用 EventStorming 作为发现我们可以布置特定流程的好方法，从我们的事件开始，然后开始扩展并找到生成这些事件的命令，然后识别聚合，并详细说明事件风暴过程。通常，这些聚合确实很好地暗示了 API 边界在哪里。 - We have to keep in mind a lot of web APIs because they’re going over a network must be more coarse-grained than our DDD code bases that tend to be more granular and can operate in-process. So when you go to a distributed architecture where we have web APIs, we don’t want to have too much network traffic. We don’t want to be too chatty. So we have to start looking at how are we interacting over the network, which is a different architectural style than how we might architect a standalone code base and process. - Looking at DDD, we really want to focus first on the aggregates, and then allow that aggregate to help drive the API operations. ### Event Storming - [Event Storming demo & discussion](https://www.youtube.com/watch?v=xIB_VQVVWKk) - Gherkin Feature File ```feature Feature: Booking a room for a hotel Policies： - All room must be paid in advance - Holody period "Super Saver" rate is 200/night Scenario: Booking a saver rate in summer school holiday Given: I am not a Loyaity Card Holder Wehn I book a room for 2 nights during ``` - [EventStormingをやってみた話](https://qiita.com/98lerr/items/9b1c50348dcaa925e1a5)  ### Misc - [A Japanese robot cafe shows how avatars can foster human connection](https://qz.com/work/2082476/a-robot-cafe-staffed-by-remote-disabled-workers-wins-japans-top-design-prize/) - 残障人士远程操作机器人的咖啡厅。 #科技的意义 - **Context Switch** - [5 Difficult Skills That Pay Off Exponentially in Programming](https://levelup.gitconnected.com/5-difficult-skills-that-pay-off-exponentially-in-programming-702a599c636e) - Most programmers’ brains are like monoliths. What they need to be is like microservices. - It is natural that clarity + skill-building precedes coding. It is also true that **you must fail fast by getting your hands dirty**. But those things need not lie in the software domain or the industry. Software, after all, - [Think Different. Think Users.](https://foundersatwork.posthaven.com/think-different-think-users) - So here are my four points about thinking differently. One, you'll need to be prepared to do it. Two, you shouldn't just do it gratuitously; you should do it in the course of serving users. Three, if you make those users happy, it will give you the strength to resist the force of convention. And four, the gap between users' view of you and the outside world's view of you is a sign of your potential. - [I programmed some creatures. They Evolved.](https://www.youtube.com/watch?v=N3tRFayqVtk) > Genome, Simple Nature Selection: right side reproduction) - Self-reproduciton - Blueprint - Inherit - Mutation