Jin Shang（尚晋）

How We Built an AI-Native Organization at Offloop

2026-11-12T00:00:00+00:00

At nine in the morning, Loopie sends me its daily brief on WeChat: two new candidates are waiting for my call. My co-founder is traveling for the next two days, so it suggests I look at them directly. Each candidate comes with one line: the screening score, what they have built, and which interview round it recommends. At the end it reminds me that a candidate from the day before is still undecided.

I reply with one sentence: “I’ll interview both. Send me the résumés.” A few minutes later both résumés are in my hands, and Loopie has already gone into each candidate’s channel to tell the HR agent and the recruiter to find a time. The next day it simply sends the candidates my calendar booking link and lets them pick a slot. It only comes back to me when no time works at all.

The morning brief, translated from Chinese, with candidate details blurred: two new candidates, a screening score and a recommended next round for each, and a reminder about one left over from the day before.

From sourcing and screening to background checks and scheduling, I made exactly one decision in this whole process: interview or not.

We get messages like this every day. Our company has no full-time HR person and no full-time finance person. Agents do the recruiting and the bookkeeping. We also have a product called Readever that is run entirely by agents, from growth to product iteration, without a single dedicated employee.

Offloop is the product we are building: a workspace where agent employees and people work together. An agent employee has its own role and responsibilities. It stays on the job, moves work forward on its own, and comes to a person only when a judgment is needed. For the past year we have been building this product and running our own company on it at the same time.

The Offloop workspace home: channels organized by function on the left, the messages that need my attention in the middle, and the agent employees on duty on the right. Message text translated from Chinese.

All of this kept me thinking about one question: what should an AI-native organization actually look like? This essay is my answer. It starts from a very old question: why do organizations divide labor at all?

1. Why we divided labor in the first place

Two reasons to divide labor

Ability. No one can do everything.
Time. One person can do it, but cannot do all of it. This is often the real constraint. Someone who understands product, engineering, algorithms, and evaluation still has only a dozen or so working hours in a day, so the work gets split into four jobs.

What each split costs

In The Mythical Man-Month, Fred Brooks wrote down the observation that later became known as Brooks’s law:

Adding manpower to a late software project makes it later.

The reason is communication. Among n people there are n(n−1)/2 lines of communication. Triple the headcount and the number of lines grows roughly tenfold. New people first need time to learn the project’s context, and the people already on it have to stop working to explain it.

Brooks’s answer was the “surgical team”: one chief surgeon who owns the core design and the key decisions, with everyone else in a supporting role. That gives up some parallelism in exchange for conceptual integrity. The system has one person’s thinking in it from start to finish, and is not stitched together from many. In his view that mattered more than a few extra pairs of hands.

Later, in No Silver Bullet, he separated two kinds of complexity. One comes from tools and implementation: languages, compilers, debugging. The other comes from the problem itself: what exactly to build, and how the parts fit together. Better tools keep reducing the first kind. The second kind does not go away. What AI solves today is mostly the first kind too.

Brooks was writing about a single team. Scale the same cost up to a whole company and it decides where the company’s boundary sits. In 1937 Ronald Coase asked a very basic question: if markets can coordinate the division of labor through prices, why do firms exist at all? His answer in The Nature of the Firm:

The main reason why it is profitable to establish a firm would seem to be that there is a cost of using the price mechanism.

Getting something done through the market means finding people, negotiating, signing contracts, and monitoring delivery. When those costs are higher than the cost of arranging the work inside a company, the work moves inside. Put another way, work that needs context passed back and forth all the time ends up inside the firm.

Oliver Williamson built on Coase and spelled out which work belongs inside: the more specific it is to this company (knowledge and relationships that are only useful here), the more uncertain, the more frequent, and the harder to measure, the more reason to do it yourself. In today’s terms, the more a piece of work depends on internal context, the more it should stay in the company.

From one team to one company, the conclusion is the same. Dividing labor adds capacity, but every additional split adds another round of passing context. We accepted that cost because without the split, the work would never get done.

2. Have these constraints been lifted?

The time constraint is mostly gone. The ability constraint is partly gone. The cost of dividing labor has not moved at all.

	Before	Now
Time	Could do it, but not all of it	Mostly lifted: execution goes to agents, and one person can move two or three things forward at once
Ability	No one can do everything	Partly lifted: agents cover the weak spots
Cost of dividing labor	Every handoff means passing the context again	Unchanged: people still hold meetings, write documents, and confirm things over and over

The reasons for dividing labor are disappearing. The cost of dividing labor is still here.

This means that, for the first time, a highly capable person can be used in full. Take product and engineering. These used to be two people: product wrote a requirements document and handed it to engineering, and if engineering understood it slightly differently, the result had to be redone. Now one person reads the user feedback, works out what to change, has an agent write the code and run the tests, and then judges the result. There is no handoff in the middle, so there is nothing to misunderstand.

Hire one more person and you add a pile of communication. Add one more agent and you only add capacity. The condition is that all of these agents see the same context.

3. The new bottlenecks

Once execution is no longer scarce, three other things are.

Human attention. There is a limit to how many things one person can keep in mind at once. With agents that number goes from one to maybe two or three. Beyond that, judgment starts to slip.
Communication between people. Agents share context with each other at almost no cost. An agent coming to a person takes up that person’s attention. People aligning with each other on direction and taste is the slowest and most expensive of all.
Verification. Agents produce more and more, and the people and standards that can tell good from bad do not keep up. Whether you can hand a piece of work to an agent with confidence depends on whether its correctness can be checked.

The further left a piece of work sits, the more it has a right answer, and the more it can already be handed to agents. The further right, the more it depends on taste, and the harder it is to know quickly whether it was done well, so people still have to do it. Agents can take over exactly as far as the evals have been written. That is why the scarcest people in an organization are the ones on the right: those who can set direction and make trade-offs.

4. Do the old organizational practices still hold?

Treating the cost of passing context as the central problem of organization is not a new idea. For decades good companies have used management systems to push that cost down. They differ only in the means. I count five kinds of practice:

Practice	Who does it	What it depends on
Write the context down and make it public	Netflix talks about “context, not control”; Amazon reads a six-page memo before every meeting; Meta’s code and documents are open to almost every employee	Someone willing to write and someone with time to read; documents go stale and need a maintainer
Keep teams small	Amazon’s two-pizza teams; Basecamp staffs a project with one designer and one or two engineers	Everyone has to be very good; Netflix hiring only the best is the price of this
One owner for each thing	Amazon’s single-threaded owner; Apple’s DRI; Netflix names one person to make each major call	That person’s energy decides how much they can own
Teams connect only through interfaces	Amazon requires teams to work with each other only through APIs; Netflix talks about “highly aligned, loosely coupled”	The interfaces must be well designed; alignment on direction still happens person to person
Fewer layers, decisions pushed down	Amazon sorts decisions into one-way and two-way doors; in 2023 Meta cut layers of middle management under “flatter is faster”	The front line needs enough context; managers take on more direct reports and more information

All of these work, but all of them rest on the same assumption: people write the context, people read it, people pass it on. So all of them hit the same ceiling, which is human time and attention. Netflix’s “give context” requires managers to spend a great deal of time explaining background. Amazon’s six-page memos need someone to write them and someone to read them. After Meta cut its middle layers, each manager had more people to manage directly.

What AI changes

Sharing context goes from culture to system. “Write the context down” used to be a cultural demand that relied on people’s discipline. Now agents can record decisions, the reasons behind them, and progress as they work, and they can read the relevant parts for a person and boil them down. What Netflix and GitLab pushed hard for and found difficult to really achieve becomes the default behavior of the infrastructure.

The size of a “small team” changes. A two-pizza team is six to ten people, and that number was propped up by the amount of execution. With execution handed to agents, two or three people plus a group of agents can own the same scope. The scope a single-threaded owner can handle grows with it.

Decisions can be pushed down to agents, not only to front-line employees. Amazon says to hand reversible decisions to the front line quickly. Some of those can now go to agents. The test has not changed. It only gains one more item: can the correctness of the result be checked?

Flattening is no longer limited by human bandwidth. Meta cut its middle layers at the price of each manager handling more people and more information. Now each person’s personal agent can pick out the relevant parts of the shared context for them. There can be fewer layers without people drowning in information.

What does not change

Each thing still needs one person who owns it. DRI, single-threaded owner, informed captain: none of these designs is out of date in the age of AI. They matter more. An agent can move things forward, but someone has to set the goal and someone has to answer for the outcome.

Talent density matters more. Netflix hires only the best because each person’s judgment affects a large part of the business. Now each person has a group of agents behind them, one judgment reaches further, and the bar for people only goes up.

Alignment on direction and taste still happens only between people. The “highly aligned” half was never accomplished through documents. It comes from people talking things through again and again. AI does not bring this cost down. Organizational design can only reduce the number of people who need to align this way.

What is not written down, the agent cannot see. Amazon’s six-page memo forces people to write their thinking out clearly. This matters more in the age of AI: agents can only use the context that has been written down.

So what AI changes is who carries the load. Recording, organizing, and distributing context can be handed to the system. What does not change is judgment and accountability. They stay with people, and they become more concentrated.

5. What the new organization should look like

Very few people, each able to play several roles. All context is shared. Any execution work whose correctness can be checked goes to agents, and people sign off on it. Each person has a personal agent that guards their attention.

Concretely, that comes to six practices. The first three are things the companies in section 4 have long been doing, except that the system now carries them and not people. The last three only became possible with agents.

Practice	Bottleneck it addresses
All context is shared, and written down	Communication
Few people, and each block of context has exactly one owner	Communication
If you must split, split where the two sides need to talk least, and connect them through explicit deliverables	Communication
Execution work that can be checked goes to agents that stay on the job	Verification
One personal agent per person, which passes along only what needs their judgment and does not interrupt them with progress updates	Attention
Whether to let an agent act on its own depends on two things: can the result be checked, and can a mistake be undone	Verification

What kind of work suits an agent that stays on the job? I use four criteria: the work recurs; whether it was done right can be checked; the context it needs sits in one place; and one person is accountable for it. Evaluation is an example: after every code change, an agent runs the eval suite, pulls out the failing samples, and hands them to the product owner.

6. Offloop: designed around this idea

We call the agents in Offloop “agent employees.” An agent employee is not a tool that waits to be called. It is a colleague that stays on the job around one role and one set of responsibilities. It knows what it owns, starts on its own when an event arrives, and keeps pushing the work forward without being chased until there is a result. It comes to a person only when a human judgment is needed. Today’s chat assistants, coding agents, and workflow automations all still need a person to trigger them.

The precondition is to bring the context together first. The product has four layers, which map directly onto the practices above:

Shared context. A team’s conversations, tasks, files, decisions, and every run record live in the same workspace, and people and agents look at the same copy. Shared does not mean without boundaries: memory is split into public and private, and a person’s email can be read only by their own personal agent.
Agents that stay on the job. Each agent has its own role, job description, skills, and permissions. It can be woken by an email, a schedule, a production alert, or another agent. Nobody has to call it.
Personal agents. One per person. As we designed it, it watches its owner’s email and calendar and speaks up only when something needs their attention. Anything it prepares on their behalf needs their approval before it goes out. The principle we set for it is “delegate, don’t impersonate.”
People. They set goals, make judgments, and answer for results. When a human judgment is needed, the agent delivers the question and the evidence together to that person’s Inbox.

Our own company runs this way.

Offloop has no full-time HR or finance staff. The recruiting agent sources continuously, scores candidates against the role, and hands a summary to the founders. A person decides only whether to interview. Sending the invitation and scheduling go back to the agent. The finance agent does everything from syncing transactions, bookkeeping, and reconciliation through monthly close and tax filing. A person authorizes access once, at the very beginning.

Engineering works the same way. Every bug has its own thread in a channel. The bug-fixing agent claims the bug, writes the fix, adds tests, and says plainly which parts are not finished yet. Teammates can drop a screenshot or an instruction into the same thread at any time, and it carries on from there.

The auto-bug-fix channel in the Offloop workspace: one thread per bug on the left, the agent's execution reports and teammates' follow-ups on the right. Message text translated from Chinese.

Closing

Fifty years ago Brooks said that adding people to a late project only makes it later. Since then almost every effort in organization has been a fight against the cost of passing context. Splitting into small teams, writing memos, naming owners, cutting middle layers: all of them try to make context travel fewer times.

AI lets us add capacity without adding people for the first time. It also lets context travel without people carrying it for the first time. That brings the question of organization back to its most basic form: who makes the judgment, and who is accountable.

Go back to the morning brief at the start. From sourcing and screening to scheduling, I made exactly one decision in the whole process: interview or not. This is what I understand an AI-native organization to be: very few people, each person’s judgment used in full, and everything else handed to agent employees that stay on the job.

The best companies of the future will not be the ones with the most people, or the ones with the most agents. They will be the ones where every person’s judgment is used in full. We are building Offloop so that more teams can run this way, and we are a team that runs this way ourselves.

References

Frederick Brooks, The Mythical Man-Month (1975) and No Silver Bullet (1986)
Ronald Coase, The Nature of the Firm (1937); Oliver Williamson, transaction cost economics
Netflix Culture: context, not control; highly aligned, loosely coupled; informed captain
Jeff Bezos, 2015 letter to shareholders (one-way and two-way door decisions); Amazon’s two-pizza teams, single-threaded owners, and six-page memos

How We Built an AI-Native Organization at Offloop was originally published by Jin Shang at Jin Shang（尚晋） on November 12, 2026.

How to Design Products in the Second Half of AI

2026-11-12T00:00:00+00:00

Every time GPT or Claude ships a new model, X fills up with jaw-dropping work: nine casual photos turned into a 3D studio you can walk through, a paper turned into an eight-minute explainer video, one person building an original game in 24 hours.

Look again a few months later, and most AI products are the same as before.

The model made the demo. It did not make the product. The gap between the two is what this essay is about: in the age of AI, a product has to be designed together with the model.

I’m Jin Shang, CEO of Offloop. This essay comes out of our recent work at Offloop on co-designing models and products.

Key takeaways

Designing the product is designing the scenario. Designing the scenario is designing the eval. Designing the eval is designing the model.

An AI product’s capability comes from the model, so the product has to be designed together with the model: growth, evals, product, harness, and model all iterate around the same scenario.
Two things are the hardest: finding the scenario users actually want, and turning it into a good eval.

1. How AI products differ from traditional products

A traditional product goes from requirement to feature. Engineers write the feature, and once it is written it stays fixed.
An AI product’s capability comes from the model, and the model changes every few months. What it cannot do today, the next version may do. A feature you force together with prompts today, the next version may simply know how to do.
So an AI product cannot be built from a feature list. A better way is to first write down who it is for, what they want done, and how good counts as done, and then see which part the model, the harness, and the product each need to fill in. That is the scenario described below.

2. Model-product co-design around the scenario

The scenario is the basic unit for designing an AI product:

Scenario = People × Task × Capability × Expected outcome

For example: figure collectors × turn a character image into a figure × 3D generation × a printable model with correct anatomy within a day.

The examples in the table below all come from real work people posted on X using new models such as GPT and Claude.

People	Task	Capability	Expected outcome	Source
Real estate agents, landlords	Turn a few listing photos into a walkable 3D home and a promo video	3D reconstruction	Listing prep drops from days to hours; the layout matches the photos	Zillow listing, studio from 9 photos
Robotics researchers	Watch a video of a person demonstrating a task and have a robot arm do the same	Robot control	Gets it right on the first try; success rate meets the bar	learning from physical demonstration
Researchers, students	Turn a paper into an eight-minute explainer video	Rendering video with code	The main thread is clear and there are no factual errors	3Blue1Brown style
Parents with kids	Build a playable open-world game from the kid’s ideas	Game generation	Done in an afternoon, and the kid wants to keep playing	making a game with my son
Indie developers	Build an original game alone	Game generation	A playable version within 24 hours	full workflow
Patients	Understand what their injury actually is	Interactive 3D explanation	Can explain the injury in their own words, matching the doctor’s conclusion	ankle anatomy
Busy urban professionals	Send a voice message to buy daily goods, order groceries, book a cleaner	Personal errands	The right things get bought, without placing the order yourself	Meta Muse
Travelers abroad	Book a full itinerary and talk to hotels in the local language	Personal errands	Every meal is booked, without making a single call yourself	Japan itinerary

Jobs-to-be-Done, a framework widely used in consumer goods, is a good way to analyze a scenario.
A need can be functional, and it can also be social or emotional.
JTBD comes down to: who, in what situation, wants to do what, to get what outcome.

A job has three parts: the functional need, the social and emotional need, and the product's features.

3. Why the eval is the core

If the expected outcome cannot be written as a test you can run again and again, you cannot tell whether a change made things better or worse, and the product cannot iterate.
The reverse also holds. With a good enough eval, and a model whose basic ability is at a passing level, raising that capability becomes very easy: changing prompts, extending the harness, and post-training all have a clear target.
Shunyu Yao makes the same point in The Second Half: the first half of AI was about who had the better training method, and the second half is about who can define the right problem and design a good eval.

4. The team

Product leads everything. The product lead decides which scenarios to bet on first and which layer to change, and coordinates the other roles. Product and harness can be the same group of people.
Model, evals, and growth each have their own team. Evals are best kept black-box.

Role	What it takes in practice
Product lead	A lot: has to understand product, engineering, models, and growth, and lead the whole thing
Product manager	User research skills and hands-on engineering ability
Harness engineering	Abstraction and system design
Model	Technical judgment and data skills
Evals	Independence, rigor, organizational efficiency
Growth	Strong execution and solid data
Creators	Heavy model users with taste

Role	Dimensions it cares about	Scenario leads it can provide	What it owns
Growth	People, task	New needs and new uses in community, user, and content feedback	Amplifying once the eval passes
Evals	Task, expected outcome	Unexpected failures or unexpectedly high scores	Building tests for each new scenario and judging whether each change passes
Product	All four	User analysis, community content, an understanding of the model	Deciding which scenarios to bet on first and which layer to change: prompts and skills, the harness, or the model
Harness	Capability	After a new tool or environment is connected, the model can do things it could not do before	Providing the runtime, tools, and context, and filling in general capabilities
Model	Capability	New capabilities that show up during training	A capability card before each release; taking scenario packs for post-training or model selection

The product lead is the biggest single point of failure in this setup. They need product design ability and an understanding of engineering, models, and growth at the same time.

5. The workflow

Anyone can discover a scenario, and product collects them into a scenario table. Product finds scenarios in the unexpected ways users use the product. The other roles provide leads: community and customer needs that growth sees, unexpected results in evals, tools and environments newly connected to the harness, new capabilities that show up in model training.
A new scenario gets an eval first: the expected outcome is written as repeatable tests with scoring criteria. (This is very hard!)
If the eval passes, creators make content around the scenario and growth scales it up. If it does not pass, it goes back to product, which decides which layer to change, and it is evaluated again after the change.

The data flywheel of model-product co-design

Changes come in three layers, from easy to hard: prompts and skills; the harness; model post-training.
Each time the model iterates, the first two layers get simpler.
Most scenarios can be made to work in the first two layers. Only the ones neither layer can solve go to model post-training.
Keep the model and the harness as general as possible. The product layer can be customized to the product’s form. General things stay at the bottom and specific things go on top, which follows the end-to-end principle (the classic 1984 system design paper by Saltzer, Reed, and Clark).
The new uses and new needs that scaling brings out become new scenarios in turn.

How a scenario moves through the flywheel

Closing

Models will keep getting stronger, and demos will keep getting easier to make. Two things are truly scarce: knowing what outcome users actually want, and being able to turn that outcome into a test you can run again and again.

The next time a new model ships, do not rush to build a demo. First write down your scenario: who it is for, what they want done, and how good counts as done. If you can write it, you have a starting point for a product. If you cannot, no number of demos will amount to more than noise.

References

Shunyu Yao, The Second Half
J. H. Saltzer, D. P. Reed, D. D. Clark, End-to-End Arguments in System Design (1984)

How to Design Products in the Second Half of AI was originally published by Jin Shang at Jin Shang（尚晋） on November 12, 2026.

How to Build a Good Personal Agent (Part 1): Product, Team, and Tech

2026-11-12T00:00:00+00:00

This is Part 1 of “How to Build a Good Personal Agent.” It covers what a personal agent is, the eight principles behind a good one, and how to build it: the team, the product, and the tech. Part 2 covers business model and strategy: whether the platform tax gets competed away, whether hardware or software becomes the entry point, and how big companies and startups each win.

Last month in San Francisco, right before returning my rental car, I texted Instinct: “How do I get to the SFO rental car return?”

The answer was direct. It knew which company I’d rented from, when the car was due, where the last gas station on the way into the airport was, and which terminal to head to after drop-off. I never told it I was returning a car that day. Two weeks earlier I had mentioned the rental in passing, and it remembered. My flight was on my calendar, and it saw that too.

One question about the SFO car return. It pulled in my rental booking, my flight, and a gas station on the way, then told me how to get to my terminal.

That was the moment I realized this was different from every AI product I had used. It felt less like software and more like a person who was always around and knew what I was up to.

I’ve sent it more than 1,000 messages since August 19. This essay tries to explain, from the ground up, what makes a personal agent good: the eight principles it should follow, what sets its ceiling, and what it takes in team, product, and tech to build one. Everything comes back to one idea: a personal agent is a way of living.

In the second half of this year, Silicon Valley’s AI products converged on this almost at once: Instinct in iMessage, Meta’s Muse, OpenAI’s Dots, Manus’s Cue. The form is converging: always on, running in the cloud, with an identity of its own. The split is the entry point: a contact in your phone, or a standalone app. Three things matured at the same time to make this possible: cloud infrastructure for always-on agents, models that are fast and cheap enough, and the demand that this year’s wave of open-source agents proved.

1. Definition: a personal agent is a way of living

2024 was the year of the chatbot. Our relationship with AI was asking. 2025 was the year of agents that do work, mostly writing code, and the relationship was supervising. Both were still tools, each solving one kind of problem. 2026 is the year of the personal agent, and it is starting to change how people live.

Tools are defined by use case: a writing tool, a translation tool, a booking tool. You have a task first, then you go find the tool. A personal agent is hard to define that way.

The 1,010 things I've handed it, spread across every corner of my life, and the range keeps widening

When I look back at those thousand-plus messages, the first impression is how scattered they are. Travel and transportation make up a quarter. Food is over a tenth. The rest is shopping, credit cards, my driver’s license, sports, news, and small talk. It replaced my search engine first. Then hotel and restaurant bookings. Then signing up for accounts and dealing with bills. None of these is a killer use case, and I don’t need it for any single one. But one small thing at a time, it became a habit I can’t replace. So here is how I’d define it:

With a tool, you have a task, then decide what to use. With a way of living, everything goes to it by default, and you only step in if it can’t handle it.

How does that default form? Delegating anything has two costs: explaining it and watching it get done. When the two add up to more than doing it yourself, you do it yourself. That’s why most AI products stall at “I use it sometimes.” A personal agent pushes both costs down. Memory makes explaining shorter every time, and being able to finish the job makes watching unnecessary. Once the cost drops past a threshold, your default flips. Trust builds the same way, one level at a time: from answering questions and giving advice, to placing orders for you and handling errands that need identity checks, and eventually to helping you keep up your relationships.

The permissions you hand over grow one level at a time

2. A good personal agent: the 8P principles

I came up with these eight principles after using every major personal agent on the market, heavily. Only two stuck and are now part of my day: Instinct and Muse. Every one I dropped broke at least two of these principles.

The eight principles are about one thing: how to get people to hand over their lives, one level at a time. Each one is a precondition for the next.

A good personal agent: the 8Ps

Principle 1 · Personable: a person, not a program

To the user, it is a person. It talks like a person and interacts like one.

It’s a contact in your phone, one long conversation with no sessions. You can interrupt it, or switch to something else mid-thread, the way you would with a friend.

Three generations of AI interfaces: the further along, the less it feels like using an agent and the more it feels like texting a person

Two common counterexamples:

Tool products with many entry points: writing, translating, image generation, and PDF reading each get their own button, so the user has to figure out which one to tap first.
The robotic voice of coding agents: even a one-line reply comes with headers, bullet points, and bold text, like a report.

So the first principle is simple: the entry point is the one people already use, and the interaction is person to person. Treat it the way you’d treat a person.

Principle 2 · Proximate: always within reach

Close enough to you: a nearby entry point, fast replies, short messages.

Three things decide the distance.

Where the entry point is. Instinct is a contact in iMessage. Messages live on your phone, so tapping it opens it, with no app to load. A standalone app adds one step, and usage drops a lot. For a product that has to become a habit, every extra step is friction.

On the other end, some products open to five tabs, each with its own row of categories and buttons. The farther a product is from the user, the less the user shows up.

How fast it replies. Speed comes first. The product itself has to be fast: open it and start talking, no splash screen, no loading. Then the replies have to be fast. Instinct and Muse are both very, very fast. Part of that is using small, fast models for the conversation. The other part is architecture: separating interaction from execution (more in Section 6). When you hand it something, it should reply right away with “Got it, on it,” then do the work in the background, so you’re not staring at a spinner. You can hand it several things in a row and it works through them one by one.

Whether it talks like a person. Many agents reply like they’re writing a report: headers, bullets, bold, and a lot of words. The reason is easy to see. Today’s smartest models are optimized for coding and complex tasks, where longer and more complete output is better. That isn’t how people text each other. A good personal agent is short and direct, like a reliable friend texting you back.

A good reply: short, direct, and human

Principle 3 · Persistent: always on

It’s the one who’s always there, even when you’re not talking to it.

AI used to exist only when you called on it. One session, one task. Close the tab and the work stops, and it forgets.

A personal agent is online 24/7. Your phone is off and it’s still working in the background. It keeps going on what you asked last week, and it remembers what you need to do tomorrow.

Being always on is the precondition for the principles that follow. It has to be there before it can know you, act first, or get things done.

Principle 4 · Personalized: it knows you, and keeps learning

The rental car story is this principle. I asked one question, “how do I get there,” and it used my booking, my flight, my location, and my habits.

When it books a restaurant, it knows what I like and picks for me. With my daily news digest, I said “fewer of these” once and it adjusted the next day. I never configured anything.

My daily news digest: one offhand comment and it gets more accurate

It works a bit like a recommendation system. Every interaction is feedback, and its understanding of you keeps accumulating and getting corrected.

Section 3 explains why this matters so much: the value of context grows exponentially. The more completely it knows you, the more it can get done.

Principle 5 · Proactive: it speaks up first

After using it for a while, most of the moments when I felt “it gets me” were moments when it spoke first.

A service alert landed in my inbox before I’d seen it, and it flagged it for me.

Proactive doesn’t mean pushy. When you open it, you see what it has already thought about for you: today’s weather, something it can take off your plate. When you don’t open it, it leaves you alone. The best kind of proactive only speaks up about things that really matter.

The best triggers are notifications that are already happening in your life: email, orders, bills, your calendar. These already need someone to deal with them. The agent just sees them before you do.

Principle 6 · Prudent: restraint

The most common failure of restraint is being too proactive: trying too hard to show off, constantly guessing what the user wants, pushing suggestions that don’t really apply, guessing wrong more often than right, until the user just wants to turn it off. A good personal agent does the opposite. It sees most of what happens in your day, notes it, and quietly takes care of it, without bothering you. It only speaks up when something actually changes your plans.

That’s restraint: no promotions, no bragging about what it did, no interruptions when it isn’t sure, and speaking up only when it’s worth it.

The same 18 events: an over-proactive agent pings you about every one, a prudent agent speaks up about two

While its judgment is still imperfect, there’s a middle ground. Muse’s feed works this way. The main screen holds only what matters most, and less important reminders and suggestions go into a feed. If you go looking, it’s there. If you don’t, it doesn’t interrupt you.

Muse's feed: the less important stuff waits here until you look

Being proactive and showing restraint are really the same skill: judging whether something is worth interrupting you for. Done well, it feels like someone with good judgment. Done badly, it’s an annoying salesperson.

That judgment depends on a strong, recommendation-style personalization system. It has to know you very well to know when to step in and when to hold back, what to bring to you and what to skip. That makes proactivity, restraint, and Principle 4’s “knowing you” two sides of the same coin: the deeper it knows you, the better its judgment.

Principle 7 · Productive: it finishes the job

I asked Instinct to help me register an Apple Developer account. That used to take forever: company details, a D-U-N-S number, form after form. It walked through every step and only left payment and identity verification to me.

One message, and it walked through the Apple Developer account step by step

When I asked it to plan a route, it gave me a map I could use right away, no written directions needed.

Route planning: it just hands you a map you can use

What’s interesting is that none of these were features built for me. Nobody sat down and thought “users might want to register for an Apple Developer account” and built a feature. It worked because it has a set of general capabilities (search, a browser, email, payments, an execution environment) and figured out how to combine them on its own.

This leads to the most counterintuitive part of building a personal agent: don’t design features, design the environment.

Traditional product managers start from use cases and build one feature per use case. A personal agent faces an endless long tail of needs. You’ll never finish building the scenarios you can imagine, and the more features you build, the more complex the product gets and the weaker its general capability becomes.

The right approach is abstract first, then specific; general first, then specialized. Take a hundred needs, group them, pull out the few general capabilities underneath, give those to the agent, and let the uses emerge on their own. The product team defines the types. Users generate the instances.

People’s underlying needs come down to a few: laziness, wanting control, wanting information, wanting company. What meets those needs is capability and environment.

Principle 8 · Private: privacy and safety

The more you hand it, and the more important those things are, the more you need to feel safe.

Being trustworthy means at least four things:

Data stays on the device. The most private data, like your message history, is processed locally on your phone and never uploaded.
Permission item by item. Each capability and each piece of data is something the user turns on. Out of the box, it takes nothing.
It never touches your card. You confirm every payment. Only then is a single-use credential issued, and the agent never sees your card number.
Traceable and reversible. Everything it does is logged, and mistakes can be rolled back.

Paying in Muse: the user connects Stripe Link, the card stays with Stripe, and the agent never sees it

Privacy decides how far trust can go. Without it, no matter how well the other seven are done, people will only trust it with small things.

3. What sets the ceiling: context and closed loops

More context, exponentially more value

A personal agent’s value comes from combining context. Combinations aren’t just pairs; any number of pieces can come together. With n kinds of information you get 2ⁿ combinations, so every new kind doubles the total. An agent with half the context gets far less than half the value. The gap is exponential. That’s why people will concentrate their context in one agent.

Double the information and the combinations grow eightfold: it's not just pairs, any set of pieces can combine

The model sets the floor, the closed loop sets the ceiling

How strong a personal agent can get depends on how complete its context is and how closed its loop is: the entry point, personal context, execution, payments, and social relationships. Are they in one place, and do they reinforce each other?

Look at how the current wave in the US is pieced together. The entry point is borrowed from iMessage or WhatsApp. Personal context is stitched together from Gmail, Calendar, and other services, one permission at a time. Execution relies on a browser clicking around like a person. Payments come from plugging in Stripe. Social relationships are scattered across platforms. Every piece is borrowed, and every seam is friction.

So the same model, given fuller context and a more complete loop, becomes a stronger agent. The model sets the floor. The closed loop sets the ceiling.

The ceiling is set by context and closed loops

4. Team: last generation’s playbook can’t build a personal agent

Three common traps

Trap 1: Building the agent as a stack of features. The experience comes from general capabilities layered with context, so features don’t add up to it. This generation should design the environment and let capabilities emerge.

Trap 2: Every business unit builds its own agent. Context gets fragmented, and the investment only adds up linearly. This generation should build one hub that every business contributes to.

Trap 3: Product, engineering, and models each own their own piece. Deciding “can we build this?” spans three layers, and the handoffs become the bottleneck. This generation needs one full-stack owner and atomic teams.

The problem is that last generation’s product methods and org structures don’t fit agents. It has nothing to do with how good any particular team is. Startups are small and full-stack by nature, so they’re less likely to fall into these traps. The bigger the company, the more likely it is to use familiar methods for an unfamiliar job.

The owner should understand models, engineering, and product

In AI products, deciding “can we build this?” spans three layers: change the prompt, change the harness, or do post-training. If those three layers sit with three different people, a feature bounces between product, engineering, and the model team, and no one can make the call. Every extra handoff slows iteration by a beat.

PMs used to know what was possible. In AI products, that call spans prompt, harness, and model

So the owner should understand models, engineering, and product, so they can decide which layer a problem belongs to and make the call on the spot. That person also needs two things:

Product taste: restraint, invisibility, simplicity. Some teams building personal agents end up with a progress dashboard. Others end up with a row of tabs and templates. A good personal agent opens to a conversation.
Learning extremely fast: agent techniques turn over every few months. Judgment can only come from the front line: using it every day and changing it yourself.

Atomic teams: evals, engineering, and model close the loop

The basic unit of the org is a small atomic team, replacing the split into product, engineering, and research groups. Each team has three roles:

Evals: set benchmarks, watch metrics, and find problems in real usage.
Engineering: build the harness, integrations, and infrastructure that make capabilities real.
Model: do post-training so the model fits the harness and the use cases.

Evals finds a problem, engineering and model fix it together, evals verifies, and nothing waits on another team’s roadmap. The hub is made of a few of these teams: few people, high density, each owning one capability or one class of use cases: entry point and interaction, harness, memory, proactivity, model. Everyone works with agents. Nobody scales by adding headcount.

Teams used to be split by function, with features handed back and forth. Now each small team closes the loop on evals, engineering, and model

Design product, harness, and model together

The three form a flywheel:

New product features become new skills in the harness. Problems users hit drive the harness to improve itself.
Harness improvements directly improve the user experience.
User data flows back into model training. Traces and environments from the harness become post-training tasks.
Model improvements unlock new product use cases.

Every turn makes the product more useful and better at understanding people.

The data flywheel linking product, harness, and model

5. Product: design for the agent

For people, the more human the better. For the agent, the more general the environment the better.

In practice, that means six things:

Treat it as a person: it’s a contact in your phone and talks in chat. No new app, no new tab.
Be fast: reply in seconds, keep it short. Slow work goes to the background, and it tells you when it’s done.
Design the product for the agent: anything a person can do in the product, the agent can do.
Design the environment, not features: give it general capabilities instead of custom UI for single use cases.
Abstract, don’t integrate one by one: we define the types, users generate the instances.
Let features emerge: only basic capabilities generalize, and only what generalizes lets new uses emerge.

Look at a few things I’ve used it for. None was a purpose-built feature. Each was a few general capabilities that the model combined on its own:

Register an Apple Developer account: search to find the process, a browser to fill out forms, email to receive verification, and payment left for me to confirm.
“How do I get to the SFO rental car return?”: the rental booking from memory, the flight from my calendar, my current location, and a search for a gas station on the way.
Plan a route: search, plus an artifact: a map I can use right away.
A daily news digest: a scheduled trigger, search, and memory. One offhand “fewer of these” changes it.

The product team’s job is to make the basics solid (search, browser, email, payments, artifacts, scheduling) and leave the combining to the model. Once something works, the approach is saved as a skill, so next time it’s faster and more reliable.

Don’t design UX, design AX

Every agent product has two interfaces: one for people and one for the agent. They should be the same.

The agent is a user just like a person. Anything a person can do, it can do, with the same set of capabilities. However a person sends messages, pays, or checks notifications, that’s how the agent does it too. Don’t build custom UI for the agent. Custom UI means you’re imagining scenarios on the user’s behalf, and you’ll never finish imagining them.

Good UX means people don’t have to think. Good AX means the agent doesn’t have to guess.

Context should also be earned one level at a time

User trust builds one level at a time, and context should be collected the same way, starting with what’s least sensitive before touching what’s private:

What the user gives it: what they say in chat, and the files and links they forward.
What the user has already made public: posts and content they already share with friends.
Interest signals the platform already uses: the ones its recommendations already rely on.
What the user grants item by item: notifications, orders, calendar, each turned on by the user.
The most private: message history, read only on the device and never uploaded. Or not used at all.

The first four levels barely touch privacy and are already enough to do a great job of getting things done for you. Only when a use case moves up a level does the context it needs move up a level.

A2A: it serves more than just you

The next step for a personal agent is dealing with other people on your behalf.

Talking to a business’s AI: refunds, flight changes, customer support. Your agent talks directly to the business’s AI agent. Both sides are agents, so once things are clear, it’s done.
Joining a group chat: planning dinner with friends or a family trip. Add it to the group, it helps everyone decide, and then it books it.

Both will feel most natural on platforms that already carry relationships between people, and between businesses and their customers.

6. Tech: models and the harness

Overview: a different kind of system from past agents

Personal agents vs. the agents before them

In one line: a personal agent is a long-running process. Here’s each piece.

Model: it needs almost the opposite of a coding agent

Today’s smartest models are optimized for coding: the more complex the task the better, the longer and more complete the output the better, and they talk like they’re writing a report. A personal agent needs four other things:

Fast: the interaction layer has to be low latency.
Talks like a person: short and natural, no reports.
Reliable tool calls: it doesn’t need to be brilliant, but it can’t get calls wrong.
Cheap: it’s always on.

So the most sensible route is to start from a fast, cheap open-weight model and do your own post-training on two kinds of tasks:

Harness capability tasks: tool calls, operating inside apps and web pages, reading and writing memory, talking like a person.
Scenario tasks: booking restaurants, doctor’s appointments, changing flights, planning trips, running errands for family.

Stage one uses SFT for cold start and distillation: a strong model works through tasks in the environment, high-quality trajectories are filtered out, and the model learns to use tools and talk like a person. Stage two uses RL: the model works through tasks in a simulated environment and is rewarded for finishing the task, calling tools correctly, and being short and human. After launch, real traces and user feedback flow back in as new tasks. Capabilities are the foundation. Scenarios are the exam.

Post-training: SFT for cold start and distillation, RL on tasks, real traces become new tasks

Harness: give it general capabilities and let the uses emerge

The agent needs a general enough environment. Abstracted from a large set of real needs, it looks roughly like this:

Search: access the web and look anything up.
Browser: operate web pages like a person: appointments, reservations, orders.
In-app actions: use services that already exist on the platform: ordering, booking, paying bills.
Payments: pay on your behalf once authorized, without touching your card.
Multimodal: voice conversations, phone calls, understanding images.
Artifacts: deliver something usable, like a web page or a route map.
Execution environment: a bash shell, the lowest-level foundation that can run anything.
External connectors: calendar, documents, and other outside services.

A few key design choices:

A minimal harness. One agent loop and a set of general tools. Weak models need a heavy harness. Good models only need a light one. Every time the model improves, you should delete something from the harness.

Minimal harness: one loop, a few general tools

Mirror every product action as a command the agent can use. Every action a person can take in the product (send a message, look up history, check notifications, pay) becomes a command-line instruction. Reveal them progressively and grant them one by one, instead of dumping hundreds of tools on the model at once.

Mirror every action a person can take as a command for the agent

Load skills on demand. Write up “how to get something done” as a guide. The index stays in context, and the full text is read only when needed. After a task succeeds, what was learned becomes a new skill.

Skills: index always in context, full text on demand, distilled after success

External services: first-party integrations for the important ones, browser use and computer use for the rest. High-frequency, important services like rides, food delivery, and shopping integrate directly, exposing capabilities through an API or MCP. That’s fastest and most reliable. The long tail doesn’t need an API: the agent uses computer use inside apps and browser use on the web, the way a person would. Both paths share the same identity and payment authorization.

For service providers, the deeper the integration, the more likely the agent picks them. Beyond exposing capabilities, they can push events (order status, arrival reminders) to the agent through webhooks, and bring their own UI into the conversation as cards.

External services: first-party integration for the head, computer use and browser use for the long tail

Service integration: capabilities, events, UI

Payments use single-use credentials only. Authorize, payment request, user confirms, single-use credential issued, merchant charges, transaction logged. The agent never touches the user’s card at any point.

Payments: single-use credentials, the agent never touches your card

Separate interaction from execution

A personal agent has to reply in seconds and also finish complicated work. In a single synchronous loop, those two goals conflict. The fix is to split it into two layers:

Interaction agent: a low-latency model that only handles conversation and dispatches tasks, replying right away with “Got it, on it.”
Work agents: pull tasks from a queue and run them asynchronously and in parallel, each in its own sandbox. They record progress and delivery status, then report back to the user through the interaction agent. If there’s nothing worth saying, they stay quiet.

Hand off several things, no waiting

Separating interaction from execution: the architecture

Runtime: harness, sandbox, and filesystem, separated

Past agents ran in a single execution environment whose lifetime equaled one task. A personal agent has to stay online, so the agent runtime, execution environment, and storage need to be separated. The agent’s state is persistent (durable execution). Execution environments can be scheduled on demand in the cloud or on the device. Storage is independent of any single run. If any piece goes down, it still remembers you and picks up where it left off.

The most direct benefit of this split is cost. Giving every user an always-on cloud computer costs around $10 a month. Once the three are separated, the agent’s state lives in durable storage, and execution environments spin up only when there’s real work and shut down when it’s done. That brings the cost to under $1 per user per month. For a product that has to stay always on for a huge number of users, that’s the difference between possible and not.

Agent runtime, execution environment, and storage, separated

Context: layered around the person

A personal agent manages one conversation that never ends, so context can’t be “stuff in all the history.” It should be layered: persona, tools, the skills index, what it knows about you, relevant memories, what’s in progress, the current conversation, and task instructions. The interaction agent and the work agents each take what they need.

Layered context

Memory: a knowledge graph of people and relationships

The old approach was memory isolated by task, plus one big file about the user. A personal agent needs a knowledge graph built around people and relationships: you, your family and friends, what you’re working on, your preferences, all connected. A background process keeps curating it: merging, correcting, and forgetting.

Memory is really a recommendation problem: at this moment, what about you is most worth remembering?

From memory isolated by task to a knowledge graph of people and relationships

Proactivity: two-tier triggers

Proactivity can’t mean having a big model watch everything all the time. That’s too expensive and too noisy. Use two tiers of triggers:

Fast rule filtering: events (new email, new orders, new notifications) and scheduled jobs come in, and cheap rules decide whether to handle them.
The agent decides when needed: only what passes the filter goes to the agent, which decides whether to remind you, ask you, or stay quiet, and records its progress.

This is also how restraint is implemented in the tech: for most events, the final decision should be “don’t interrupt.”

Two-tier triggers: rules filter, the agent decides when needed

Self-improvement

Users run into small problems every day, and triaging them by hand can’t keep up. So give the personal agent its own tool for reporting problems. When it can’t do something well, it reports the issue with its context. A separate coding agent reads these issues and the run traces, then changes the harness. Changes are replayed against historical traces, and only those that pass go out in a staged rollout.

Self-improvement: report issues, a coding agent fixes, replay to verify, staged rollout

Privacy: draw a clear line

The agent loop runs in the cloud. The most sensitive data, like message history, stays in a local execution environment on the phone and never crosses that line. The cloud only gets what the user has granted, item by item. The clearer the line, the more people are willing to hand over.

Muse’s approach is a good reference (based on what Meta has published):

A separate review process: a Sentinel isolated from the agent checks every outbound action against what the user authorized, and allows it, blocks it, or asks the user to confirm.
Credentials never enter the model: account tokens and passwords live in a separate credential service and are issued to the execution environment only when needed. The model never sees them.
Sensitive actions ask first: sending an email or placing an order needs the user’s confirmation.
Users can see and revoke: each connection can be read-only or read-write and revoked at any time, everything it did is logged and reviewable, and you can ask it to forget what it remembered.

Safety: every outbound action passes a checkpoint first

Conclusion

Definition: a personal agent is a way of living. Tools are defined by use case. A personal agent has no killer use case. It becomes an irreplaceable habit through many small things: everything goes to it first, by default.
The 8P principles: a good personal agent behaves like a person. It shows up like a person, talks like a person, is always around, knows you, thinks ahead, has judgment, gets things done, and can be trusted.
The ceiling: intelligence is already in surplus. The model sets the floor, and context and closed loops set the ceiling. The value of context grows exponentially.
Team: last generation’s playbook can’t build a personal agent. The owner should understand models, engineering, and product, and the org is made of atomic teams where evals, engineering, and model close the loop together.
Product: design the environment, not features. Give the agent general capabilities and let uses grow out of real usage. Design AX, not just UX.
Tech: separate interaction from execution, separate the runtime into three parts, layer the context, build memory as a knowledge graph, use two-tier triggers, let it improve itself, and draw a clear line for privacy.

So the hardest part isn’t the tech. It’s restraint in the product and an AI-native org: having the nerve to build only the environment, and letting one person who understands all three layers, with a small full-stack team, design the product, harness, and model together.

When you stop feeling like you’re using an AI product, it has worked.

Coming next. This was Part 1 of “How to Build a Good Personal Agent,” on product, team, and tech. Part 2 covers business model and strategy: whether the platform tax gets competed away, whether hardware or software becomes the entry point, and how big companies and startups each win.

How to Build a Good Personal Agent (Part 1): Product, Team, and Tech was originally published by Jin Shang at Jin Shang（尚晋） on November 12, 2026.

C++17在业务代码中最好用的十个特性

2022-05-15T00:00:00+00:00

C++17在业务代码中最好用的十个特性

自从步入现代C++时代开始，C++语言标准形成了三年一个版本的惯例：C++11标志着现代C++的开端，C++14在11的基础上查缺补漏，并未加入许多新特性，而C++17作为C++11后的第一个大版本，标志着现代C++逐渐走向成熟。WXG编译器升级到gcc7.5已有一段时间，笔者所在项目组也已经将全部代码升级到C++17。在使用了c++17一年多之后，笔者总结了C++17在业务代码中最好用的十个特性。

注1：本文只包含wxg的gcc7.5支持的特性，Execution Policy, File System等暂不支持的特性不包含在内。

注2：本文只包含应用于业务逻辑的特性，Fold Expression, Mathematical Special Functions等适用于元编程和科学计算的特性并不包含。

笔者将这些特性大体上分为三类：语法糖、性能提升和类型系统

语法糖

这里所说的语法糖，并不是严格意义上编程语言级别的语法糖，还包括一些能让代码更简洁更具有可读性的函数和库：

结构化绑定

c++17最便利的语法糖当属结构化绑定。结构化绑定是指将array、tuple或struct的成员绑定到一组变量*上的语法，最常用的场景是在遍历map/unordered_map时不用再声明一个中间变量了:

// pre c++17
for(const auto& kv: map){
  const auto& key = kv.first;
  const auto& value = kv.second;
  // ...
}

// c++17
for(const auto& [key, value]: map){
  // ...
}

*: 严格来说，结构化绑定的结果并不是变量，c++标准称之为名字/别名，这也导致它们不允许被lambda捕获，但是gcc并没有遵循c++标准，所以以下代码在gcc可以编译，clang则编译不过

for(const auto& [key, value]: map){
    [&key, &value]{
        std::cout << key << ": " << value << std::endl;
    }();
}

在clang环境下，可以在lambda表达式捕获时显式引入一个引用变量通过编译

for(const auto& [key, value]: map){
    [&key = key, &value = value]{
        std::cout << key << ": " << value << std::endl;
    }();
}

另外这条限制在c++20中已经被删除，所以在c++20标准中gcc和clang都可以捕获结构化绑定的对象了。

std::tuple的隐式推导

在c++17以前，构造std::pair/std::tuple时必须指定数据类型或使用std::make_pair/std::make_tuple函数，c++17为std::pair/std::tuple新增了推导规则，可以不再显示指定类型。

// pre c++17
std::pair<int, std::string> p1{3.14, "pi"s};
auto p1 = std::make_pair(3.14, "pi"s);

// c++17
std::pair p3{3.14, "pi"s};

if constexpr

if constexpr语句是编译期的if判断语句，在C++17以前做编译期的条件判断往往通过复杂SFINAE机制或模版重载实现，甚至嫌麻烦的时候直接放到运行时用if判断，造成性能损耗，if constexpr大大缓解了这个问题。比如我想实现一个函数将不同类型的输入转化为字符串，在c++17之前需要写三个函数去实现，而c++17只需要一个函数。

// pre c++17
template <typename T>
std::string convert(T input){
    return std::to_string(input);
}

// const char*和string进行特殊处理
std::string convert(const char* input){
    return input;
}
std::string convert(std::string input){
    return input;
}

// c++17
template <typename T>
std::string convert(T input) {
    if constexpr (std::is_same_v<T, const char*> ||
                  std::is_same_v<T, std::string>) {
        return input;
    } else {
        return std::to_string(input);
    }
}

if初始化语句

c++17支持在if的判断语句之前增加一个初始化语句，将仅用于if语句内部的变量声明在if内，有助于提升代码的可读性。且对于lock/iterator等涉及并发/RAII的类型更容易保证程序的正确性。

// c++ 17
std::map<int, std::string> m;
std::mutex mx;
extern bool shared_flag; // guarded by mx
 
int demo()
{
    if (auto it = m.find(10); it != m.end()) { return it->second.size(); }
    if (char buf[10]; std::fgets(buf, 10, stdin)) { m[0] += buf; }
    if (std::lock_guard lock(mx); shared_flag) { unsafe_ping(); shared_flag = false; }
    if (int s; int count = ReadBytesWithSignal(&s)) { publish(count); raise(s); }
    if (const auto keywords = {"if", "for", "while"};
        std::ranges::any_of(keywords, [&tok](const char* kw) { return tok == kw; }))
    {
        std::cerr << "Token must not be a keyword\n";
    }
}

性能提升

std::shared_mutex

shared_mutex是c++的原生读写锁实现，有共享和独占两种锁模式，适用于并发高的读场景下，通过reader之前共享锁来提升性能。在c++17之前，只能自己通过独占锁和条件变量自己实现读写锁或使用c++14加入的性能较差的std::shared_timed_mutex。以下是通过shared_mutex实现的线程安全计数器：

// c++17
class ThreadSafeCounter {
 public:
  ThreadSafeCounter() = default;
 
  // Multiple threads/readers can read the counter's value at the same time.
  unsigned int get() const {
    std::shared_lock lock(mutex_);
    return value_;
  }
 
  // Only one thread/writer can increment/write the counter's value.
  unsigned int increment() {
    std::unique_lock lock(mutex_);
    return ++value_;
  }
 
  // Only one thread/writer can reset/write the counter's value.
  void reset() {
    std::unique_lock lock(mutex_);
    value_ = 0;
  }
 
 private:
  mutable std::shared_mutex mutex_;
  unsigned int value_ = 0;
};

std::string_view

std::string_view顾名思义是字符串的“视图”，类成员变量包含两个部分：字符串指针和字符串长度，std::string_view涵盖了std::string的所有只读接口。std::string_view对字符串不具有所有权，且兼容std::string和const char*两种类型。

c++17之前，我们处理只读字符串往往使用const std::string&，std::string有两点性能优势:

兼容两种字符串类型，减少类型转换和内存分配。如果传入的是明文字符串const char*, const std::string&需要进行一次内存分配，将字符串拷贝到堆上，而std::string_view则可以避免。
在处理子串时，std::string::substr也需要进行拷贝和分配内存，而std::string_view::substr则不需要，在处理大文件解析时，性能优势非常明显。

// from https://stackoverflow.com/a/40129046
// author: Pavel Davydov

// string_view的remove_prefix比const std::string&的快了15倍
string remove_prefix(const string &str) {
  return str.substr(3);
}
string_view remove_prefix(string_view str) {
  str.remove_prefix(3);
  return str;
}

static void BM_remove_prefix_string(benchmark::State& state) {                
  std::string example{"asfaghdfgsghasfasg3423rfgasdg"};
  while (state.KeepRunning()) {
    auto res = remove_prefix(example);
    // auto res = remove_prefix(string_view(example)); for string_view
    if (res != "aghdfgsghasfasg3423rfgasdg") {
      throw std::runtime_error("bad op");
    }
  }
}

std::map/unordered_map try_emplace

在向std::map/unordered_map中插入元素时，我们往往使用emplace，emplace的操作是如果元素key不存在，则插入该元素，否则不插入。但是在元素已存在时，emplace仍会构造一次待插入的元素，在判断不需要插入后，立即将该元素析构，因此进行了一次多余构造和析构操作。c++17加入了try_emplace，避免了这个问题。同时try_emplace在参数列表中将key和value分开，因此进行原地构造的语法比emplace更加简洁

std::map<std::string, std::string> m;
// emplace的原地构造需要使用std::piecewise_construct，因为是直接插入std::pair<key, value>
m.emplace(std::piecewise_construct,
           std::forward_as_tuple("c"),
           std::forward_as_tuple(10, 'c'));

// try_emplace可以直接原地构造，因为参数列表中key和value是分开的
m.try_emplace("c", 10, 'c')

同时，c++17还给std::map/unordered_map加入了insert_or_assign函数，可以更方便地实现插入或修改语义

类型系统

c++17进一步完备了c++的类型系统，终于加入了众望所归的类型擦除容器(Type Erasure)和代数数据类型(Algebraic Data Type)

std::any

std::any是一个可以存储任何可拷贝类型的容器，C语言中通常使用void*实现类似的功能，与void*相比，std::any具有两点优势：

std::any更安全：在类型T被转换成void*时，T的类型信息就已经丢失了，在转换回具体类型时程序无法判断当前的void*的类型是否真的是T，容易带来安全隐患。而std::any会存储类型信息，std::any_cast是一个安全的类型转换。
std::any管理了对象的生命周期，在std::any析构时，会将存储的对象析构，而void*则需要手动管理内存。

std::any应当很少是程序员的第一选择，在已知类型的情况下，std::optional, std::variant和继承都是比它更高效、更合理的选择。只有当对类型完全未知的情况下，才应当使用std::any，比如动态类型文本的解析或者业务逻辑的中间层信息传递。

std::optional

std::optional<T>代表一个可能存在的T值，对应Haskell中的Maybe和Rust/OCaml中的option，实际上是一种Sum Type。常用于可能失败的函数的返回值中，比如工厂函数。在C++17之前，往往使用T*作为返回值，如果为nullptr则代表函数失败，否则T*指向了真正的返回值。但是这种写法模糊了所有权，函数的调用方无法确定是否应该接管T*的内存管理，而且T*可能为空的假设，如果忘记检查则会有SegFault的风险。

// pre c++17
ReturnType* func(const std::string& in) {
    ReturnType* ret = new ReturnType;
    if (in.size() == 0)
        return nullptr;
    // ...
    return ret;
}

// c++17 更安全和直观
std::optional<ReturnType> func(const string& in) {
    ReturnType ret;
    if (in.size() == 0)
        return nullopt;
    // ...
    return ret;
}

std::variant

std::variant<T, U, ...>代表一个多类型的容器，容器中的值是制定类型的一种，是通用的Sum Type，对应Rust的enum。是一种类型安全的union，所以也叫做tagged union。与union相比有两点优势：

可以存储复杂类型，而union只能直接存储基础的POD类型，对于如std::vector和std::string就等复杂类型则需要用户手动管理内存。
类型安全，variant存储了内部的类型信息，所以可以进行安全的类型转换，c++17之前往往通过union+enum来实现相同功能。

通过使用std::variant<T, Err>，用户可以实现类似Rust的std::result，即在函数执行成功时返回结果，在失败时返回错误信息，上文的例子则可以改成:

std::variant<ReturnType, Err> func(const string& in) {
    ReturnType ret;
    if (in.size() == 0)
        return Err{"input is empty"};
    // ...
    return {ret};
}

需要注意的是，c++17只提供了一个库级别的variant实现，没有对应的模式匹配(Pattern Matching)机制，而最接近的std::visit又缺少编译器的优化支持，所以在c++17中std::variant并不好用，跟Rust和函数式语言中出神入化的Sum Type还相去甚远，但是已经有许多围绕std::variant的提案被提交给c++委员会探讨，包括模式匹配，std::expected等等。

总结一下，c++17新增的三种类型给c++带来了更现代更安全的类型系统，它们对应的使用场景是：

std::any适用于之前使用void*作为通用类型的场景。
std::optional适用于之前使用nullptr代表失败状态的场景。
std::variant适用于之前使用union的场景。

总结

以上是笔者在生产环境中最常用的c++17特性，除了本文描述的十个特性外，c++17还添加了如lambda值捕获*this, 钳夹函数std::clamp(), 强制检查返回值[[nodiscard]]等非常易用的特性，本文篇幅有限不做赘述，欢迎有兴趣的读者自行探索。

C++17在业务代码中最好用的十个特性 was originally published by Jin Shang at Jin Shang（尚晋） on May 15, 2022.

JustMySocks+Qv2ray极简教程

2020-08-03T00:00:00+00:00

justmysocks 官网链接

标准价格：$5.88/月起

最低价格：年付只需交10个月+优惠码（JMS9272283）永久优惠5.2% = 389 人民币/年

下面这段广告引用自搬瓦工JMS

justmysocks 是搬瓦工官方提供的优质 V2Ray 服务和 Shadowsocks 服务，最好的 CN2 GIA 线路，月付仅 $5.88 起，更有高达 5G 带宽的 CN2 GIA 线路可选！被墙自动换 IP，无须担心 IP 被墙！！！

justmysocks 支持 V2Ray 协议！V2Ray 是最新的黑科技加持的技术，相比 Shadowsocks 来说更加安全，高效，隐蔽。而 JustMySocks 又同时支持 V2Ray 和 Shadowsocks ，为我们提供更多选择。

justmysocks 使用优质 CN2 GIA 高速线路，无论白天还是晚上，你都无须担心网络问题，并且有五组服务器节点备用，最最最重要的一点是无须担心 IP 被墙问题！！！这可是解决了所有人最担心的痛点啊哈哈哈哈

justmysocks 适合那些不想自己买 VPS 折腾搭建的用户，又或者是担心 IP 被墙的，然后网络速度也要比较优秀稳定的，还不用担心跑路的。当然这对新手小白用户是特别友好的，买了就能用，其他任何屁事都不用自己打理，只管用就好。

我们一般将提供 V2Ray 服务或 Shadowsocks 服务的商家，俗称机场，或者飞机场。所以可以将 JustMySocks 称作为搬瓦工机场。或者叫 JMS 机场！

由于是搬瓦工提供的服务，所以不用担心跑路之类的啦~ 当然，搬瓦工机场不同于其他机场，如果购买了觉得不满意，也是支持退款的！

并且最重要的一点是 justmysocks 不同于那些国人的机场，justmysocks 是搬瓦工官方背书的，数据安全是绝对靠谱放心的，无须有任何顾虑。

Just My Socks 优势

搬瓦工出品，服务安全可靠

被墙自动换 IP，无须担心 IP 被墙

支持退款，放心无忧

支持支付宝付款

最好的 CN2 GIA 线路

高达 5G 带宽的 CN2 GIA 线路可选

TCP & UDP 协议支持

支持更改密码

支持更改服务器端口

购买的部分我们就略过了，总之购买之后你的service界面划到最下面会有五个二维码和五个链接（只考虑via jamjams.net domain name 的五个，因为会动态更新ip）。它们就是我们的通关密语。下面教大家如何使用：

电脑端

使用Qv2ray，教程参考：https://qv2ray.net/getting-started/。教程细节很多，实际就四步：

从Github Release下载对应系统的Qv2ray版本
从V2Ray Core下载对应系统的v2ray core版本
打开Qv2ray首选项-内核设置，找到核心可执行文件目录路径，把下载的v2ray core解压拷贝进去然后验证就可以了
新建链接，把五个通关密语链接拷贝进来即可

选择任意一个连接，连接之后Mac和Windows电脑会自动使用Qv2ray代理。可以在设置里选择绕过中国大陆，这样大陆网站就不会走代理，直连速度会更快。

手机端

ios端推荐Shadowrocket，海外账号app store可下，app里直接扫上面的二维码就可添加连接。android端推荐Kitsunebi， play store可下。

其他客户端请参考官方推荐https://www.v2ray.com/awesome/tools.html

JustMySocks+Qv2ray极简教程 was originally published by Jin Shang at Jin Shang（尚晋） on August 03, 2020.

Tree Traversal

2019-10-23T00:00:00+00:00

Tree traversal algorithms: pre_order, in_order, post_order

void preorder_traversal_iteratively(TreeNode* root)
{
	if (root == 0)
		return;
	stack<TreeNode*> s;
	s.push(root);
	cout << root->val << ' '; // visit root
	TreeNode* last_pop = root;
	while (!s.empty())
	{
		TreeNode* top = s.top();
		if (top->left != 0 && top->left != last_pop && top->right != last_pop) // push_left
		{
			s.push(top->left);
			cout << top->left->val << ' '; // visit top->left
		}
		else if (top->right != 0 && top->right != last_pop && (top->left == 0 || top->left == last_pop)) // push_right
		{
			s.push(top->right);
			cout << top->right->val << ' '; // visit top->right
		}
		else // pop
		{
			s.pop();
			last_pop = top;
		}
	}
}

void inorder_traversal_iteratively(TreeNode* root)
{
	if (root == 0)
		return;
	stack<TreeNode*> s;
	s.push(root);
	TreeNode* last_pop = root;
	while (!s.empty())
	{
		TreeNode* top = s.top();
		if (top->left != 0 && top->left != last_pop && top->right != last_pop) // push_left
		{
			s.push(top->left);
		}
		else if (top->right != 0 && top->right != last_pop && (top->left == 0 || top->left == last_pop)) // push_right
		{
			s.push(top->right);
			cout << top->val << ' '; // visit top
		}
		else // pop
		{
			s.pop();
			last_pop = top;
			if (top->right == 0)
				cout << top->val << ' '; // visit top
		}
	}
}

void postorder_traversal_iteratively(TreeNode* root)
{
	if (root == 0)
		return;
	stack<TreeNode*> s;
	s.push(root);	
	TreeNode* last_pop = root;
	while (!s.empty())
	{		
		TreeNode* top = s.top();
		if (top->left != 0 && top->left != last_pop && top->right != last_pop) // push_left
		{
			s.push(top->left);
		}
		else if (top->right != 0 && top->right != last_pop && (top->left == 0 || top->left == last_pop)) // push_right
		{
			s.push(top->right);
		}
		else // pop
		{
			s.pop();
			last_pop = top;
			cout << top->val << ' '; // visit top
		}
	}
}

Tree Traversal was originally published by Jin Shang at Jin Shang（尚晋） on October 23, 2019.

SweepLine

2019-10-23T00:00:00+00:00

SweepLine algorithm for finding all intersections

sweepLineIntersection(Points[0..2n-1]):
1. Sort Points[] from left to right (according to x coordinate) (priority_queue)

2. Create an empty Self-Balancing BST T. It will contain all active line 
   Segments ordered by y coordinate. (map)

// Process all 2n points 
3. for i = 0 to 2n-1
	pq.pop()
    // If this point is left end of its line  
    if (Points[i].isLeft) 
       T.insert(Points[i].line())  // Insert into the tree

       // Check if this points intersects with its predecessor and successor
       if ( doIntersect(Points[i].line(), T.pred(Points[i].line()) )
         return true
       if ( doIntersect(Points[i].line(), T.succ(Points[i].line()) )
         return true

    else  // If it's a right end of its line
       // Check if its predecessor and successor intersect with each other
       if ( doIntersect(T.pred(Points[i].line(), T.succ(Points[i].line()))
         return true
       T.delete(Points[i].line())  // Delete from tree

4. return False

SweepLine was originally published by Jin Shang at Jin Shang（尚晋） on October 23, 2019.

Palinedrome Number

2019-10-23T00:00:00+00:00

Determine whether an integer is a palindrome. An integer is a palindrome when it reads the same backward as forward.

Example 1:

Input: 121
Output: true

Example 2:

Input: -121
Output: false
Explanation: From left to right, it reads -121. From right to left, it becomes 121-. Therefore it is not a palindrome.

Example 3:

Input: 10
Output: false
Explanation: Reads 01 from right to left. Therefore it is not a palindrome.

Solution:

1) If x is negative, return false;

2) Create x’s inverse. Be careful with overflow!

3) Check if inverse == x;

class Solution {
public:
    bool isPalindrome(int x) {
        if(x<0) return false;
        int z = x;
        int y = 0;
        while(x){
            if(y < (INT_MAX-(x%10))/10){
                y *= 10;
                y += x%10;
            }
            else{
                return false;
            }
            
            x /= 10;
        }
        return z==y;
    }
};

Palinedrome Number was originally published by Jin Shang at Jin Shang（尚晋） on October 23, 2019.

String to Integer (atoi)

2019-10-23T00:00:00+00:00

Implement atoi which converts a string to an integer.

The function first discards as many whitespace characters as necessary until the first non-whitespace character is found. Then, starting from this character, takes an optional initial plus or minus sign followed by as many numerical digits as possible, and interprets them as a numerical value.

The string can contain additional characters after those that form the integral number, which are ignored and have no effect on the behavior of this function.

If the first sequence of non-whitespace characters in str is not a valid integral number, or if no such sequence exists because either str is empty or it contains only whitespace characters, no conversion is performed.

If no valid conversion could be performed, a zero value is returned.

Note:

Only the space character ' ' is considered as whitespace character.
Assume we are dealing with an environment which could only store integers within the 32-bit signed integer range: [−231, 231 − 1]. If the numerical value is out of the range of representable values, INT_MAX (231 − 1) or INT_MIN (−231) is returned.

Example 1:

Input: "42"
Output: 42

Example 2:

Input: "   -42"
Output: -42
Explanation: The first non-whitespace character is '-', which is the minus sign.
             Then take as many numerical digits as possible, which gets 42.

Example 3:

Input: "4193 with words"
Output: 4193
Explanation: Conversion stops at digit '3' as the next character is not a numerical digit.

Example 4:

Input: "words and 987"
Output: 0
Explanation: The first non-whitespace character is 'w', which is not a numerical 
             digit or a +/- sign. Therefore no valid conversion could be performed.

Example 5:

Input: "-91283472332"
Output: -2147483648
Explanation: The number "-91283472332" is out of the range of a 32-bit signed integer.
             Thefore INT_MIN (−231) is returned.

Solution:

Implementation Task. Just be careful with INT overflow. Note that INT_MAX = -INT_MIN-1.

class Solution {
public:
    int myAtoi(string str) {
        if(str.empty()) return 0;
        int i = 0, sign = 1;
        while(i < str.size() && str[i]==' ') i++;
        if(i == str.size()) return 0;
        int res = 0;
        if(str[i] == '-'){
            sign = -1;
        }else{
            if(str[i] == '+'){
                sign = 1;
            }else if(str[i] >= '0' && str[i] <= '9'){
                res = sign*(str[i] - '0');
            }
            else{
                return 0;
            }
        }
        i++;
        while(i < str.size() && str[i] >= '0' && str[i] <= '9'){
            int x = str[i] - '0';
            if(sign==-1){
                if(res >= ((INT_MIN+x)/10)){
                    res = res*10 - x;
                }
                else{
                    return INT_MIN;
                }
            }
            else{
                if(res <= ((INT_MAX-x)/10)){
                    res = res*10 + x;
                }
                else{
                    return INT_MAX;
                }
            }
            i++;
        }
        return res;
        
    }
};

String to Integer (atoi) was originally published by Jin Shang at Jin Shang（尚晋） on October 23, 2019.

Daily temperatures

2019-10-23T00:00:00+00:00

Given a list of daily temperatures T, return a list such that, for each day in the input, tells you how many days you would have to wait until a warmer temperature. If there is no future day for which this is possible, put 0 instead.

For example, given the list of temperatures T = [73, 74, 75, 71, 69, 72, 76, 73], your output should be [1, 1, 4, 2, 1, 1, 0, 0].

Note: The length of temperatures will be in the range [1, 30000]. Each temperature will be an integer in the range [30, 100].

Solution:

Iterate backwards and maintain a stack, pop until stack top is more than current element.

class Solution {
public:
    vector<int> dailyTemperatures(vector<int>& T) {
        stack<pair<int,int>> s;
        vector<int> ans(T.size());
        for(int i = T.size()-1; i>=0; i--){
            while(!s.empty() && s.top().first <= T[i]){
                s.pop();
            }
            if(s.empty()) ans[i] = 0;
            else ans[i]=s.top().second-i;
            s.push(make_pair(T[i],i));
        }
        return ans;
    }
};

Daily temperatures was originally published by Jin Shang at Jin Shang（尚晋） on October 23, 2019.

Edit distance

2019-10-23T00:00:00+00:00

Given two words word1 and word2, find the minimum number of operations required to convert word1 to word2.

You have the following 3 operations permitted on a word:

Insert a character
Delete a character
Replace a character

Example 1:

Input: word1 = "horse", word2 = "ros"
Output: 3
Explanation: 
horse -> rorse (replace 'h' with 'r')
rorse -> rose (remove 'r')
rose -> ros (remove 'e')

Example 2:

Input: word1 = "intention", word2 = "execution"
Output: 5
Explanation: 
intention -> inention (remove 't')
inention -> enention (replace 'i' with 'e')
enention -> exention (replace 'n' with 'x')
exention -> exection (replace 'n' with 'c')
exection -> execution (insert 'u')

Sol:

Simple DP. Possible to save space.

class Solution {
public:
    int minDistance(string word1, string word2) {
        int n = word1.size();
        int m = word2.size();
        if(word1.empty()) return m;
        if(word2.empty()) return n;
        vector<vector<int>> dp(n+1, vector<int>(m+1,1e9));
        for(int i = 0; i < n+1; i++){
            for(int j = 0; j < m+1; j++){
                if(i == 0) dp[i][j] = j;
                else if(j == 0) dp[i][j] = i;
                else{
                    if(word1[i-1] == word2[j-1]){
                        dp[i][j] = min(dp[i][j], dp[i-1][j-1]);
                    }else{
                        dp[i][j] = min(dp[i][j], dp[i-1][j-1]+1);
                    }
                    dp[i][j] = min(dp[i][j], dp[i-1][j]+1);
                    dp[i][j] = min(dp[i][j], dp[i][j-1]+1);
                }
            }
        }
        return dp[n][m];
    }
};

Edit distance was originally published by Jin Shang at Jin Shang（尚晋） on October 23, 2019.

Reverse Integer

2019-10-23T00:00:00+00:00

Given a 32-bit signed integer, reverse digits of an integer.

Example 1:

Input: 123
Output: 321

Example 2:

Input: -123
Output: -321

Example 3:

Input: 120
Output: 21

Note: Assume we are dealing with an environment which could only store integers within the 32-bit signed integer range: [−231, 231 − 1]. For the purpose of this problem, assume that your function returns 0 when the reversed integer overflows.

Solution:

to_string() and stol()

class Solution {
public:
    int reverse(int x) {
        bool sign = (x<0);
        long long ans;
        long long y = x;
        if(sign) y*=-1;
        string s = to_string(y);
        std::reverse(s.begin(),s.end());
        ans = stol(s);
        if(sign) ans*=-1;
        if(ans>INT_MAX||ans<INT_MIN) return 0;
        return (int)ans;
    }
};

Reverse Integer was originally published by Jin Shang at Jin Shang（尚晋） on October 23, 2019.

Palindromic Substrings

2019-10-23T00:00:00+00:00

Given a string, your task is to count how many palindromic substrings in this string.

The substrings with different start indexes or end indexes are counted as different substrings even they consist of same characters.

Example 1:

Input: "abc"
Output: 3
Explanation: Three palindromic strings: "a", "b", "c".

Example 2:

Input: "aaa"
Output: 6
Explanation: Six palindromic strings: "a", "a", "a", "aa", "aa", "aaa".

Note:

The input string length won’t exceed 1000.

Solution:

Expand from middle

First do it for odd-length.

Then add “ “ inbetween every character and find ones with even length,

class Solution {
public:
    int countSubstrings(string s) {
        int ans = 0;
        for(int i =0; i <s.size();i++){
            int cur = 0;
            while(i-cur>=0 && i+cur<=s.size()-1 && s[i-cur] == s[i+cur]){
                cur++;
            }
            ans+=cur;
        }
        string ss = " ";
        for(char c: s){
            ss+=c;
            ss+=' ';
        }
        s = ss;
        for(int i =0; i<s.size();i+=2){
            int cur = 0;
            while(i-cur>=0 && i+cur<=s.size()-1 && s[i-cur] == s[i+cur]){
                cur++;
            }
            ans += cur/2;
        }
        return ans;
        
    }
};

Note 1:

No need to add space, just enumerate the 2N-1 possible centers

class Solution(object):
    def countSubstrings(self, S):
        N = len(S)
        ans = 0
        for center in xrange(2*N - 1):
            left = center / 2
            right = left + center % 2
            while left >= 0 and right < N and S[left] == S[right]:
                ans += 1
                left -= 1
                right += 1
        return ans

Note 2:

Manacher Algorithm:

def countSubstrings(self, S):
    def manachers(S):
        A = '@#' + '#'.join(S) + '#$'
        Z = [0] * len(A)
        center = right = 0
        for i in xrange(1, len(A) - 1):
            if i < right:
                Z[i] = min(right - i, Z[2 * center - i])
            while A[i + Z[i] + 1] == A[i - Z[i] - 1]:
                Z[i] += 1
            if i + Z[i] > right:
                center, right = i, i + Z[i]
        return Z

    return sum((v+1)/2 for v in manachers(S))

Palindromic Substrings was originally published by Jin Shang at Jin Shang（尚晋） on October 23, 2019.

Task Scheduler

2019-10-23T00:00:00+00:00

Given a char array representing tasks CPU need to do. It contains capital letters A to Z where different letters represent different tasks. Tasks could be done without original order. Each task could be done in one interval. For each interval, CPU could finish one task or just be idle.

However, there is a non-negative cooling interval n that means between two same tasks, there must be at least n intervals that CPU are doing different tasks or just be idle.

You need to return the least number of intervals the CPU will take to finish all the given tasks.

Example:

Input: tasks = ["A","A","A","B","B","B"], n = 2
Output: 8
Explanation: A -> B -> idle -> A -> B -> idle -> A -> B.

Note:

The number of tasks is in the range [1, 10000].
The integer n is in the range [0, 100].

Solution: priority queue

class Solution {
public:
    int leastInterval(vector<char>& tasks, int n) {
        priority_queue<pair<int,int>> pq;
        map<char,int> cnt;
        for(char& c : tasks){
            cnt[c]++;
        }
        for(auto& p:cnt){
            pq.push(make_pair(p.second, p.first));
        }
        int ans = 0;
        int done = 0;
        while(!pq.empty()){
            vector<pair<int,int>> temp;
            for(int i =0;i<=n;i++){
                if(pq.empty()){
                    if(done == tasks.size()) return ans;
                    ans++;
                    continue;
                }
                temp.push_back(pq.top());
                pq.pop();
                done++;
                ans++;
            }
            for(auto& p:temp){
                p.first--;
                // cout<<p.second<<" ";
                if(p.first>0)pq.push(p);
            }
        }
        return ans;
    }
};

Solution: slot allocation

class Solution {
public:
    int leastInterval(vector<char>& tasks, int n) {
        vector<int> mp(26, 0);
        for (char c : tasks)
            ++mp[c - 'A'];
        sort(mp.begin(), mp.end());
        int max_num = mp[25] - 1;
        int idle = max_num * n;
        for (int i = 24; i >= 0 && mp[i] > 0; --i)
            idle -= min(mp[i], max_num);
        return idle > 0 ? idle + tasks.size() : tasks.size();
    }
};

Task Scheduler was originally published by Jin Shang at Jin Shang（尚晋） on October 23, 2019.

Merge Two Binary Trees

2019-10-23T00:00:00+00:00

Given two binary trees and imagine that when you put one of them to cover the other, some nodes of the two trees are overlapped while the others are not.

You need to merge them into a new binary tree. The merge rule is that if two nodes overlap, then sum node values up as the new value of the merged node. Otherwise, the NOT null node will be used as the node of new tree.

Example 1:

Input: 
	Tree 1                     Tree 2                  
          1                         2                             
         / \                       / \                            
        3   2                     1   3                        
       /                           \   \                      
      5                             4   7                  
Output: 
Merged tree:
	     3
	    / \
	   4   5
	  / \   \ 
	 5   4   7

Note: The merging process must start from the root nodes of both trees.

Solution:

class Solution {
public:
    TreeNode* mergeTrees(TreeNode* t1, TreeNode* t2) {
        if(t1 == NULL && t2 == NULL) return NULL;
        if(t1 == NULL) return t2;
        if(t2 == NULL) return t1;
        TreeNode* n = new TreeNode(t1->val+t2->val);
        n->left = mergeTrees(t1->left, t2->left);
        n->right = mergeTrees(t1->right, t2->right);
        return n;
    }
};

Merge Two Binary Trees was originally published by Jin Shang at Jin Shang（尚晋） on October 23, 2019.

Zigzag Conversion

2019-10-23T00:00:00+00:00

The string "PAYPALISHIRING" is written in a zigzag pattern on a given number of rows like this: (you may want to display this pattern in a fixed font for better legibility)

P   A   H   N
A P L S I I G
Y   I   R

And then read line by line: "PAHNAPLSIIGYIR"

Write the code that will take a string and make this conversion given a number of rows:

string convert(string s, int numRows);

Example 1:

Input: s = "PAYPALISHIRING", numRows = 3
Output: "PAHNAPLSIIGYIR"

Example 2:

Input: s = "PAYPALISHIRING", numRows = 4
Output: "PINALSIGYAHRPI"
Explanation:

P     I    N
A   L S  I G
Y A   H R
P     I

Solution:

Simple implementation: compute the conversion formula

class Solution {
public:
    string convert(string s, int numRows) {
        if(numRows==1) return s;
        string ans;
        int d = (numRows-1)*2;
        for(int i=0;i<numRows;i++){
            int j = i;
            while(j<s.size()){
                ans+=s[j];
                if(j%d!=0&&j%d!=numRows-1){
                    if(j/d*d+(d-(j%d))<s.size()){
                        ans+=s[j/d*d+(d-(j%d))];
                    }
                }
                j+=d;
            }
        }
        return ans;
    }
};

Zigzag Conversion was originally published by Jin Shang at Jin Shang（尚晋） on October 23, 2019.

Shortest Unsorted Continuous Subarray

2019-10-23T00:00:00+00:00

Given an integer array, you need to find one continuous subarray that if you only sort this subarray in ascending order, then the whole array will be sorted in ascending order, too.

You need to find the shortest such subarray and output its length.

Example 1:

Input: [2, 6, 4, 8, 10, 9, 15]
Output: 5
Explanation: You need to sort [6, 4, 8, 10, 9] in ascending order to make the whole array sorted in ascending order.

Note:

Then length of the input array is in range [1, 10,000].
The input array may contain duplicates, so ascending order here means <=.

Solution:

Two pass, one from left and one from right.

On left, update the current max, any element that is less than current max is the left end of this subarray.

class Solution {
public:
    int findUnsortedSubarray(vector<int>& nums) {
        int cmin = INT_MAX;
        int cmax = INT_MIN;
        int st = 1, nd = 0;
        int l = 0;
        int r = nums.size()-1;
        while(r>=0){
            if(nums[l] >= cmax){
                cmax = nums[l];
            }else{
                nd = l;
            }
            if(nums[r] <= cmin){
                cmin = nums[r];
            }else{
                st = r;
            }
            l++;
            r--;
        }
        return nd-st+1;
    }
};

Shortest Unsorted Continuous Subarray was originally published by Jin Shang at Jin Shang（尚晋） on October 23, 2019.

Subarray Sum Equals K

2019-10-23T00:00:00+00:00

Given an array of integers and an integer k, you need to find the total number of continuous subarrays whose sum equals to k.

Example 1:

Input:nums = [1,1,1], k = 2
Output: 2

Note:

The length of the array is in range [1, 20,000].
The range of numbers in the array is [-1000, 1000] and the range of the integer k is [-1e7, 1e7].

Solution:

Prefix sum. Rather than keeping the sum, keep a map of count of a certain sum.

Now for any value, we add the number of cnt[sum-k] so the sum would be k.

class Solution {
public:
    int subarraySum(vector<int>& nums, int k) {
        unordered_map<int, int> cnt;
        int sum = 0;
        int ans = 0;
        cnt[0] = 1;
        for(int i:nums){
            sum += i;
            ans += cnt[sum-k];
            cnt[sum]++;
        }
        return ans;
    }
};

Subarray Sum Equals K was originally published by Jin Shang at Jin Shang（尚晋） on October 23, 2019.

Diameter of Binary Tree

2019-10-23T00:00:00+00:00

Given a binary tree, you need to compute the length of the diameter of the tree. The diameter of a binary tree is the length of the longest path between any two nodes in a tree. This path may or may not pass through the root.

Example: Given a binary tree

Return 3, which is the length of the path [4,2,1,3] or [5,2,1,3].

Note: The length of path between two nodes is represented by the number of edges between them.

Solution:

MAX-DEPTH

class Solution {
public:
    int depth(TreeNode* root){
        if(root == NULL) return 0;
        return max(depth(root->left), depth(root->right))+1;
    }
    
    int diameterOfBinaryTree(TreeNode* root) {
        if(root == NULL) return 0;
        return max(max(diameterOfBinaryTree(root->left), diameterOfBinaryTree(root->right)), depth(root->left)+depth(root->right));
    }
};

Diameter of Binary Tree was originally published by Jin Shang at Jin Shang（尚晋） on October 23, 2019.

Longest Palindromic Substring

2019-10-23T00:00:00+00:00

Given a string s, find the longest palindromic substring in s. You may assume that the maximum length of s is 1000.

Example 1:

Input: "babad"
Output: "bab"
Note: "aba" is also a valid answer.

Example 2:

Input: "cbbd"
Output: "bb"

Solution:

Insert ‘ ‘ in between every element of string to simplify odd and even case. Then iterate through string and find the maximum length if current char is pivot.

class Solution {
public:
    string longestPalindrome(string s) {
        vector<char> t{' '};
        for(char c:s){
            t.push_back(c);
            t.push_back(' ');
        }
        int len = -1;
        int pos = -1;
        for(int i=0;i<t.size();i++){
            int l = i, r = i;
            while(l>=0&&r<t.size()&&t[l]==t[r]){
                l--;
                r++;
            }
            if(r-l+1>len){
                len = r-l-1;
                pos = l+1;
            }
        }
        vector<char> ans;
        for(int i=pos;i<pos+len;i++){
            if(t[i]==' ')continue;
            ans.push_back(t[i]);
        }
        
        return string(ans.begin(),ans.end());
        
        
    }
};

Longest Palindromic Substring was originally published by Jin Shang at Jin Shang（尚晋） on October 23, 2019.