DEV Community: Chris Noring

Understanding GitHub Billing and management: from licenses to fair AI credit controls

Chris Noring — Wed, 12 Aug 2026 13:40:44 +0000

Buying GitHub Copilot licenses is only the beginning of the governance story. The licenses are purchased centrally, but administrators still need to decide who receives a seat, how usage is attributed to the right part of the business, and what happens when included AI credits run out.

Those decisions happen through several related controls:

Copilot seat assignment determines which people are licensed.
Cost centers group attributable usage around a team or business owner.
AI credit included usage caps create boundaries around included credits associated with a cost center's licenses.
Cost-center budgets govern paid usage after included credits are exhausted.
User-level budgets (ULBs) limit how much an individual can consume.

Why does this separation matter? Without it, an administrator can easily mistake one control for another. An included usage cap does not set an overage policy, and a cost-center budget does not guarantee every person an equal share. Each control answers a different question.

This article follows the complete flow, starting before a cost center exists and ending with different policies for Business and Developers, where we place them each in separate cost centers with distinct included-usage boundaries, paid-usage budgets, and ULBs.

Series

This is part of a series on GitHub Admin and billing controls.

Managing surprise bills
Better together: GitHub Admin UI + Billing API
Understanding GitHub Billing and management: from licenses to fair AI credit controls, we're here

Problem 1: A central purchase does not identify who is licensed

Our story starts with a purchase, but purchasing seats does not yet tell us who can use Copilot. This is the first problem to solve because cost centers, budgets, and AI credit controls all depend on GitHub knowing which named users actually hold eligible licenses.

Suppose an enterprise purchases 400 Copilot seats for a workforce that includes 600 employees. The purchase creates a centrally managed pool of seats. It does not automatically license 400 unspecified people, nor does every developer receive a fraction of a license.

At this point, the enterprise knows how many seats it owns, but it cannot yet connect those seats to people, teams, or cost centers.

Solution: Assign seats to named users

An administrator assigns those seats to specific users, either directly or through the supported administrative assignment process. At that point, GitHub can distinguish between:

A person who belongs to the enterprise but has no Copilot seat.
A person who has been assigned an eligible Copilot seat.
A licensed person whose usage is attributable to a particular cost center.

This distinction matters because cost-center included credits are based on attributable eligible licenses, not raw headcount.

For example, imagine a Developers cost center containing 200 people:

Developers in the cost center	Developers with eligible Copilot seats	Licenses that can contribute to the calculation
200	200	200
200	120	120
200	0	0

The cost center does not receive an included-credit boundary based simply on having 200 members. GitHub looks at the eligible licenses attributable to those members and calculates the included amount from those licenses.

NOTE: The exact included-credit amount is calculated by GitHub according to the applicable licenses and product terms. Administrators do not manually divide the enterprise's included credits by cost-center headcount.

Now the enterprise knows who is licensed. That solves entitlement, but it creates the next question: when those users consume AI credits, which part of the business owns that usage?

Fig 1: A developer cost center

Problem 2: Licensed usage has no business owner

A list of licensed users is not yet a governance model. Finance and administrators still need to connect usage to the team, program, or financial owner responsible for it.

Why does this matter? A single enterprise can contain groups with very different usage patterns. Business Operations may have predictable demand, while Developers may run more intensive AI workflows. Treating both groups as one undifferentiated population makes it difficult to protect included usage or govern overage appropriately.

Solution: Use cost centers to establish ownership

Cost centers provide that attribution boundary around resources such as users, teams, or organizations. They do not purchase licenses or assign Copilot seats. Instead, they connect licensed activity to the part of the business responsible for it.

For this scenario, create two cost centers:

Business, containing the relevant Business users or teams.
Developers, containing the relevant engineering users or teams.

GitHub can then determine which eligible Copilot licenses are attributable to each cost center. Conceptually, the relationship is:

Cost-center included credits= ∑(included credits from eligible licenses attributed to that cost center)

This is accounting attribution, not a second license purchase. The enterprise still owns and manages the seats centrally. The cost center tells GitHub where the associated usage and included-credit entitlement belong for governance purposes.

With that ownership structure in place, GitHub can tell which licenses are attributable to Business and which are attributable to Developers. Ownership is now clear, but both groups can still participate in the same included-credit pool. That creates the next risk.

Fig 2: Developers and Business cost centers

Problem 3: One group can consume another group's included credits

By default, included AI credits can function as a shared enterprise resource. That is convenient, but it can produce an uneven outcome: one group may consume included credits funded by licenses associated with another group.

Imagine Developers has an unusually intensive month. Without a separate boundary, its members may continue drawing from the shared pool, reducing the included credits available to Business. Attribution tells us who owns the usage, but attribution alone does not protect either group's share.

Solution: Enable the included usage cap

The AI credit included usage cap changes that behavior for a cost center. When enabled, GitHub calculates an included-credit boundary from the eligible licenses attributable to that cost center.

For example, enable the checkbox for both Business and Developers. Each cost center can then use the included credits calculated from its attributable licenses without the other cost center consuming beyond its own boundary.

The safest way to describe this is:

The cost center receives a protected included-usage boundary calculated from its attributable eligible licenses.

It is tempting to call those credits "guaranteed to me," but that wording can imply more than the control provides. The boundary belongs to the cost center, not to an individual, and it does not guarantee that every member receives an equal allocation.

The shared-pool problem is now addressed, but the checkbox also exposes the next question: what happens after a cost center exhausts its protected included credits? The cap separates included usage; it does not define the paid-usage policy.

Fig 3: Included usage cap checked on a cost center

Problem 4: The included usage cap does not stop overage

Once a cost center reaches its included-credit boundary, additional eligible usage may become paid usage when paid AI credit usage is enabled. A cost-center budget determines how that overage is monitored or stopped.

Why is a separate budget necessary? The included usage cap says, "Do not continue consuming included credits beyond this cost center's calculated boundary." It does not necessarily say, "Block all subsequent usage." A spending control is required to define that second outcome.

Our two cost centers need different outcomes. Business should stop before overage, while Developers should be allowed to continue so the enterprise can observe real demand.

Solution for Business: Use a $0 hard budget

Business should use its included credits but create no overage. Configure a $0 cost-center budget and enable Stop usage when budget limit is reached.

Together, the controls mean:

Business uses the included credits associated with its attributable licenses.
The included usage cap prevents it from drawing beyond its protected included boundary.
The $0 hard budget allows no paid usage after included credits are exhausted.

The $0 budget does not prevent Business from using included credits. It establishes a zero-dollar allowance specifically for the paid-usage phase.

NOTE: If paid AI credit usage is disabled for the entire enterprise, a $0 cost-center budget may be redundant. It becomes important in this scenario because Developers must retain access to paid usage under the same enterprise account.

!Business cost center with a $0 hard budget](https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/fw05ktbkv415rph8jm5u.png)

Fig 4: Business cost center with a $0 hard budget

Solution for Developers: Start with a soft budget

Developers need more flexibility. Configure a funded cost-center budget, such as $20,000, but leave Stop usage when budget limit is reached disabled.

This is a soft budget. It provides a target and supports alerts, but it is not a hard ceiling. Usage can continue beyond $20,000 unless another applicable control stops it.

That behavior is useful while the organization learns the team's real demand. Administrators can monitor spending, review whether the usage produces value, and later decide whether to change the amount or turn on the stop control.

At this point, Business and Developers have distinct overage policies:

Cost center	Included usage	Paid-usage budget	Stop usage	Outcome
Business	Protected boundary enabled	$0	Yes	Use included credits, then stop
Developers	Protected boundary enabled	$20,000	No	Use included credits, then allow monitored paid usage

We have now defined what paid usage means for each cost center. However, the Developers budget controls the group total, not the behavior of each person inside the group. One heavy user could still consume a disproportionate amount, which leads to the next problem.

Fig 5: Developers cost center with a $20,000 soft budget and no stop control

Problem 5: An aggregate budget does not create individual fairness

The $20,000 Developers budget gives administrators visibility into aggregate paid usage, but it does not divide that amount fairly among the people in the cost center. A few heavy users could consume most of the available capacity while everyone else remains far below the group budget.

Why add a ULB when Developers already has a $20,000 budget? The two controls operate at different levels:

The $20,000 cost-center budget monitors the Developers group's aggregate paid usage.
A cost-center ULB gives each person in Developers an individual ceiling.

Solution: Add a cost-center ULB

A user-level budget limits one person's total AI credit consumption during the billing cycle. It follows the user across included and paid usage and acts as a hard stop when the applicable limit is reached.

For example, configure a $200-per-user cost-center ULB for Developers. This prevents a small number of heavy users from consuming a disproportionate amount while other users receive little opportunity to work.

The $200 value is a maximum, not a reservation. It does not set aside $200 for every person, and unused capacity from one user is not a personal entitlement that another user can claim. It simply says that each covered user stops when their individual consumption reaches $200.

This makes the policy more predictable and equitable without requiring administrators to create a separate budget for every member of the cost center. The common baseline solves the fairness problem, but a uniform limit can be too restrictive for specialized roles.

Fig 6: Developers cost center with a $200 per-user ULB

Problem 6: One baseline does not fit every role

A shared baseline will not fit every role. A platform engineer, AI lead, or approved power user may have a legitimate need for more capacity than the Developers baseline permits.

Raising the $200 limit for the entire cost center would solve that person's problem by giving everyone more capacity. That is broader than necessary and weakens the fairness policy we just established.

Solution: Add an individual override

For example, create an individual ULB of $400 for softchris. That individual policy takes precedence over the $200 Developers cost-center ULB.

The precedence is:

Individual ULB
Cost-center ULB
Universal ULB

This lets administrators start with a broad enterprise default, apply a more suitable baseline to a cost center, and reserve individual overrides for documented exceptions.

An individual override should still be reviewed. More capacity is not automatically better governance; it should correspond to an approved role or business outcome. We have now solved each problem at the narrowest appropriate scope.

Fig 7: Individual ULB override for a specific user in the Developers cost center

Resolution: See the complete control model

Now that each control has been introduced separately, we can connect them into one end-to-end model.

Purchase Copilot seats centrally. The enterprise or organization owns the seat pool.
Assign seats to named users. This establishes who holds an eligible Copilot license.
Attribute users, teams, or organizations to cost centers. This connects licensed activity to Business or Developers.
Enable the included usage cap. GitHub calculates a protected included-credit boundary from eligible licenses attributable to each cost center.
Set cost-center budgets. Business receives a $0 hard budget; Developers receives a $20,000 soft budget.
Set a cost-center ULB. Developers users receive a $200 individual ceiling.
Add approved exceptions. softchris receives a $400 individual ULB.

The resulting Budgets and alerts view tells a coherent story:

Type	Scope	Amount	Purpose
Cost center	Business	$0, stop enabled	Prevent paid overage after included usage
Cost center	Developers	$20,000, stop disabled	Observe aggregate paid usage without an immediate hard stop
User • Cost Center	Developers	$200 per user	Apply a fair individual baseline across the cost center
User	`softchris`	$400	Preserve an approved individual exception

These four rows do not show the included usage caps themselves; those are configured on the cost-center details. The rows show the controls that govern paid usage and individual consumption after the attribution model has been established.

Checkpoint: Avoid the most common misunderstandings

The controls become easier to operate when their boundaries are explicit. Keep these distinctions in mind:

Purchasing 400 seats does not automatically license an unspecified 400 people. Seats must be assigned to users.
Putting 200 people in a cost center does not mean 200 licenses contribute to its included-credit calculation. Only attributable users with eligible licenses contribute.
An included usage cap does not assign an equal number of credits to every person.
An included usage cap does not, by itself, define the cost center's paid-usage policy.
A soft cost-center budget is an observation and alerting threshold, not a hard ceiling.
A cost-center ULB is a per-user maximum, not a guaranteed allocation for each person.
An individual ULB overrides a broader cost-center or universal ULB for that user.

The easiest way to remember the model is:

Assign the license. Attribute the usage. Protect included credits. Govern paid usage. Limit the individual.

Outcome: Different teams, appropriate controls

Business and Developers now operate under the same enterprise purchase but follow policies suited to their work.

Business can consume the included credits associated with its attributable licenses and then stops before creating paid usage. Developers can continue into paid usage while administrators observe demand against a soft budget. A cost-center ULB prevents a few users from dominating consumption, while individual overrides preserve approved exceptions.

No single checkbox provides all of that behavior. The result comes from combining license assignment, cost-center attribution, included-credit boundaries, spending budgets, and ULBs in the right order.

That order is the practical governance lesson: protect included usage first, decide how paid usage should behave second, and then add per-user controls where fairness or predictability requires them.

GitHub Admin UI + Billing API: Better together for smarter spend decisions

Chris Noring — Mon, 10 Aug 2026 14:42:20 +0000

As a GitHub administrator, you already have a strong place to start when somebody asks, “Why did our AI spend go up?” In Metered usage, you can see the change, choose the period, and group the data by organization or cost center.

That first investigation often leads to questions that are specific to your company. Finance may want a month-end report based on its own reporting calendar. An engineering leader may want to see whether an increase is spread across a team or concentrated among a few people. Answering those questions once is useful; answering them repeatedly calls for a reusable approach.

Series

This is part of a series on GitHub Admin and billing controls.

Managing surprise bills
Better together: GitHub Admin UI + Billing, we're here
Understanding GitHub Billing and management

Use each surface for what it does best

The GitHub admin UI shows you where to look and gives you the controls to respond. The Billing Usage API helps you answer the recurring questions that are specific to your company. Neither replaces the other.

Together, they give administrators a practical loop: spot the change in Metered usage, understand it through a reusable API-powered view, and act with a targeted budget. That means better cost control without treating every user or team as the problem.

Let’s walk through this better-together approach using a common example: AI spend starts to rise, but the reason is not yet clear.

The question: Spend is up, but what is driving it?

Imagine that finance notices an increase in AI spend before the next close. It could be a sign that more developers are getting value from Copilot. It could also be one workload using far more than expected. At this point, nobody knows, and a broad restriction would be premature.

The GitHub administrator needs to help finance and engineering answer three practical questions:

Which part of the business is driving the increase?
Is the spend concentrated among a few users or broadly distributed?
Which control should change without disrupting everyone else?

The goal is not simply to reduce a number. It is to understand the increase well enough to protect useful work while addressing anything unexpected.

1. Start in the admin UI: Find the increase

The admin UI is the natural place to begin because it lets you explore the data before you decide what kind of report or control you need. Open Billing and licensing > Metered usage and select the relevant reporting period.

This first check matters. It confirms that the increase is real, shows when it happened, and gives you a shared starting point for the conversation with finance and engineering.

Fig 01: Metered usage establishes the increase and the period that needs investigation.

Narrow the increase by organization

An enterprise total tells you that spend changed, but not where to look next. Group the usage by organization to see which part of the enterprise contributed most to the increase.

Fig 02: Organization grouping narrows an enterprise-wide increase to an accountable business area.

Suppose the octodemo organization stands out. You now know where to continue the investigation and which leaders can add context. You do not yet know whether the spend is justified, and that distinction matters. The increase could come from successful Copilot adoption, a migration, a seasonal workload, or an automated process that needs attention.

Connect the increase to a cost center

An organization can contain several teams, programs, and budgets. Grouping by cost center takes the investigation one step closer to the people who understand the work behind the spend.

Fig 03: Cost-center grouping identifies the financial owner of the increase.

In this scenario, octodemo-org-cc has the largest increase. In only a few clicks, the admin UI has taken us from an enterprise-wide signal to the cost center that needs a closer look. For a one-time question, this may be enough.

Now imagine that finance asks for the same analysis every month, with a fixed reporting period and a ranking of spend by user. That is the point where the API adds value. It does not replace the investigation you just completed; it helps you repeat and extend it.

2. Continue with the API: Answer the repeatable question

The Billing Usage API gives you access to the data behind a more tailored report. You can use filters to match the period finance cares about, focus on the cost center you found in the UI, and build a view that can run again tomorrow or next month.

Fig 04: Billing usage endpoints and time filters provide the inputs for a reusable report.

Define the reporting question first

Before writing code, state the question the report needs to answer. In this example, it is:

Which users in the selected cost center account for the most net spend during this reporting period?

That one question keeps the report focused. It also determines the workflow:

List the organization's members to establish the candidate users.
Resolve which members belong to the selected cost center.
Query organization AI credit and premium-request usage for those users and the selected period.
Combine the results into a per-user total.
Rank users and aggregate the result by cost center.

The prototype uses year, month, and optional day filters so the output matches the finance period. It also accepts a cost-center filter. Because the admin UI has already pointed us to octodemo-org-cc, there is no reason to start with every member of the enterprise.

Understand the per-user query pattern

There is one API behavior to understand before building the report. The organization billing endpoints return an aggregate when the user filter is omitted. To create a spend-by-user ranking, the workflow makes a filtered request for each selected user and usage type.

For example, this request asks for Eve's AI credit usage in July 2026:

curl -L \
    -H "Accept: application/vnd.github+json" \
    -H "Authorization: Bearer $GITHUB_TOKEN" \
    -H "X-GitHub-Api-Version: 2026-03-10" \
    "https://api.github.com/organizations/octodemo/settings/billing/ai_credit/usage?year=2026&month=7&user=eve"

The response contains one or more usage items, with amounts such as grossAmount, discountAmount, and netAmount. The prototype adds the netAmount values to calculate Eve's AI credit total for the period. It then runs the equivalent premium-request query and combines the two totals.

We can now see one user's contribution during the same period we investigated in the UI. Repeating the request for the members of the selected cost center gives us the ranking that finance asked for.

For a production workflow, a few practical details matter:

Limit the candidate list to the cost center under investigation.
Paginate organization membership and cost-center results.
Use bounded concurrency instead of sending every request at once.
Record partial failures rather than silently treating them as zero spend.
Keep an audit record of when the data was pulled and transformed.

For a daily check, the report can use a narrow period and write a timestamped output. At finance close, the same workflow can produce the month-end rollup. The question stays the same; only the reporting window changes.

Reveal concentration that totals can hide

The result is a custom Spend by User view that brings the organization, cost center, reporting period, AI credit usage, premium-request usage, and total net spend into one place.

Fig 05: A company-specific dashboard exposes per-user concentration inside the selected cost center.

In the illustrative data, the octodemo organization has 22 users and $3,651 in total net spend for July 2026. The octodemo-org-cc cost center accounts for $2,700 of that amount. Two users stand out:

User	AI credit net spend	Premium-request net spend	Total net spend
`eve`	$900	$600	$1,500
`adam`	$600	$400	$1,000

Together, Adam and Eve account for $2,500 of the $2,700 attributed to that cost center. That is approximately 93% of its total in this example.

These figures are demonstration data, but they show why the extra view is useful. Instead of reacting to a $2,700 cost-center total, the administrator can talk to the owners of two workloads and understand what the spend supported.

Concentration does not automatically mean waste. Adam and Eve may be doing approved, high-value work. The dashboard tells the business where to ask the next question; the people involved provide the context needed to answer it.

3. Return to the admin UI: Choose the right control

The API has helped us understand the increase, but it does not make the decision for us. Return to Billing and licensing > Budgets and alerts to review the available controls and choose the narrowest one that fits what you learned.

Fig 06: Budget scopes turn the investigation into a targeted governance decision.

Set a cost-center user-level baseline

A cost-center user-level budget applies the same per-user amount to every current and future member of that cost center. This is useful when the group needs a different baseline from the rest of the enterprise.

For example, the administrator might give octodemo-org-cc additional per-user headroom because its work legitimately uses more AI credits. This avoids raising the universal user-level budget for everyone.

A user-level budget counts both included and paid AI credit usage. It is always a hard stop for the individual. It does not reserve part of the shared pool, and it does not replace the cost center's paid-usage budget.

Preserve justified exceptions

If Adam or Eve has an approved role that requires more capacity, an individual user-level budget can replace the cost-center baseline for that person. The exception stays limited to the person who needs it instead of increasing the budget for the whole cost center.

Fig 07: Cost-center baselines and individual overrides preserve useful work without widening access for everyone.

The precedence is straightforward:

An individual user-level budget overrides the cost-center user-level budget.
The cost-center user-level budget overrides the universal user-level budget.

In practice, you can set a universal baseline, add more headroom for a cost center with a clear business need, and use individual overrides for documented exceptions.

Why the UI and API work better together

At this point, the better-together pattern becomes clear:

Metered usage supports interactive discovery.
Billing Usage API supports repeatable, company-specific analysis.
Budgets and alerts supports targeted policy decisions.

Each surface does the job it is best suited to do. The UI makes it easy to explore and manage GitHub. The API lets you repeat a company-specific analysis without rebuilding it by hand. Used together, they give finance, engineering, and administrators the same evidence before a control changes.

Make it part of the operating rhythm

A useful dashboard should lead to a useful conversation. Decide who receives the report, how often they review it, and what happens when a user or cost center stands out.

For example:

Run a daily pull to detect unusual changes early.
Produce a month-end rollup aligned to finance close.
Route cost-center summaries to the relevant business owner.
Review high-consumption users with engineering before changing limits.
Record approved individual overrides and revisit them regularly.

Over time, the conversation can move from “Who spent this?” to “What outcome did this spend support, and does the current policy still fit?”

When the same users repeatedly appear at the top, leaders can inspect the workload, remove waste, validate business value, or approve more capacity. When usage becomes broadly distributed, the cost-center baseline may need adjustment instead. The report makes those patterns visible over time.

The better-together workflow at a glance

The story above introduces each surface when it becomes useful. This table summarizes their roles.

Surface	Primary role	Best used for	Important limitation
Metered usage	Interactive investigation	Finding the affected period, organization, and cost center	Manual exploration is not a reusable company-specific report
Billing Usage API	Programmatic usage retrieval	Scheduled reporting, time-sliced analysis, and per-user views	Per-user attribution requires filtered requests and careful handling of pagination and failures
Custom Spend by User view	Company-specific interpretation	Ranking users and aligning usage to internal ownership	Concentration is evidence to investigate, not proof of waste
Budgets and alerts	Governance controls	Cost-center baselines and individual overrides	A broader budget cannot override a user who has reached their ULB

The practical takeaway is simple: begin with exploration, automate only the question worth repeating, and adjust policy after the data has context. That sequence keeps governance precise while preserving useful AI work.

Learn more

Turning surprise AI bills into accountable growth with GitHub Billing Controls

Chris Noring — Mon, 27 Jul 2026 18:44:11 +0000

This is a story of how you receive a higher bill than expected and how GitHub's Billing Controls help clarity and predictability. Let's begin our story.

Series

This is part of a series on GitHub Admin and billing controls.

Managing surprise bills, you're here
Better together: GitHub Admin UI + Billing API
Understanding GitHub Billing and management

Confusion: The bill is higher than expected

The AI bill is higher than expected. Now what?

Finance wants to understand what is driving the cost. Engineering leaders, on the other hand, want to preserve the productivity gains behind the increased usage. The administrator needs to balance both priorities and put a policy in place that the business can understand.

One question drives the investigation:

Where is the increase coming from, and how do we control it without disrupting valuable work?

To answer it, we first need to follow the spend. Once we know who owns it, we can apply guardrails at the right level.

Investigation: Follow the spend

Setting a limit too early could restrict useful adoption without addressing the main source of cost. So, let's find out what changed and who can act on it.

The investigation begins in the billing administration portal, where usage and budget settings appear in one place.

Fig 01: A unified billing workspace connects usage evidence to budget controls.

Identify the consumption category

First, we identify which product changed. GitHub reports this by SKU, which simply means the billing category for a product or service.

Fig 02: Grouping metered usage by billing category highlights Copilot Enterprise usage.

Grouping usage by billing category shows which product is driving the increase. In this example, the chart points to Copilot Enterprise usage. Leaders can then ask whether that growth comes from valuable adoption, an unusual workload, or demand that has outgrown its budget.

Locate the accountable organization

Once you know which product is driving the cost, find out who owns the usage. An enterprise-wide total can hide a sharp increase in one organization.

Fig 03: Organization-level grouping identifies the business unit accountable for demand.

The organization view points to the leader who can connect that usage to business results, estimate future demand, and decide what to do next.

Connect usage to a cost center

An organization may still be too broad. A cost center is a billing group that connects usage to the team, program, or function responsible for the cost.

Fig 04: Cost-center analysis reveals concentrated usage averaging about $20,000 per month.

Here, one cost center accounts for most of the AI credit usage and averages about $20,000 per month. That gives leaders a practical starting point. A $20,000 alert may suit normal demand, while a growth team, seasonal workload, or strategic migration may need more headroom, or more room to spend before reaching the limit. The right amount depends on expected usage, financial risk, and the value the work creates.

The investigation has now produced an answer: most of the increase comes from one cost center spending about $20,000 per month. The next question is what to do about it.

Resolution: Put guardrails in place

Rather than place one restrictive limit on everyone, the administrator can add guardrails at three levels: across the organization, for the cost center driving the increase, and for individual users who need a different limit.

The Budgets and alerts page is where those decisions become policy.

Fig 05: The Budgets and alerts page provides the New budget action.

Let's start with the broadest guardrail and then make it more specific.

Set a boundary for shared paid usage

An organization budget gives finance a clear limit for usage charges. License costs are separate and do not count toward this amount.

Fig 06: A $200,000 organization budget establishes a configurable boundary for paid usage.

The $200,000 organization budget shown here is an example. The right amount depends on expected usage, available included credits, growth plans, and what would happen if paid usage stopped. This shared budget applies only to additional paid usage after included credits are used. It does not include license costs.

There is one timing detail to keep in mind: if you create the budget partway through a billing cycle, GitHub does not count usage from earlier in that cycle. The first bill can therefore exceed the displayed $200,000 limit.

The Stop usage when budget limit is reached toggle controls what happens next. Leave it off and GitHub sends notifications while usage continues. Turn it on and affected paid usage stops at the limit. GitHub Copilot code completions and next edit suggestions still work because they do not use this paid AI credit allowance. A blocked request also does not automatically switch to a cheaper model.

Create accountable room for a cost center

The organization budget covers shared paid usage across the organization. A cost-center budget gives a specific team an earlier warning.

Fig 07: A $20,000 cost-center threshold monitors current demand without stopping usage.

In this example, the administrator sets a $20,000 alert and leaves the stop toggle off. The owner can review the workload, remove waste, or ask for a higher limit before usage is interrupted.

The same timing rule applies here: if the budget is created partway through the billing cycle, earlier usage is not counted. The first bill can therefore exceed the displayed $20,000 limit.

Fig 08: Threshold alerts route emerging cost risk to owners before month-end.

Alerts give people time to act. Finance can review expected spending, the cost-center owner can explain the increase, and the administrator can adjust the limit or turn on stopping if needed.

Give different users the right limits

Shared budgets do not control how many AI credits one person can use. Per-user budgets do. They count both included and paid credits, and they always stop further AI-credit use when the person's limit is reached.

Set these limits from broad to specific:

Establish a universal per-user baseline, the starting limit for every licensed user.
Add a cost-center exception where a group's expected outcomes justify a different limit.
Add an individual override, a replacement limit for one person, only for a role with a documented need.

Fig 09: A $200 per-user cost-center exception adds targeted headroom without raising the enterprise baseline.

The screenshot shows the second step: a $200 per-user limit for one cost center. Start with the universal baseline, then add an individual override only when someone has a clear need for a different amount. This keeps exceptions easy to review and avoids raising the limit for everyone just to support one specialist.

Explain which user limit takes priority

What happens when several limits cover the same user? Precedence is simply the order GitHub follows to choose the user-level budget that applies.

Fig 10: Policy precedence applies individual overrides before cost-center and universal user limits.

Among user-level budgets, the individual override comes first, followed by the cost-center per-user budget and then the universal baseline. For example, imagine a $100 universal baseline, a $200 cost-center limit, and a $500 individual override. The specialist gets $500, colleagues in that cost center get $200 each, and everyone else gets $100 each.

Shared organization and cost-center limits still apply separately. Whichever relevant limit is reached first blocks further usage. A person may still have money left in an individual budget when the shared limit has already been reached. The reverse can also happen: a person's limit may stop their usage while the shared budget still has room.

Aftermath: Keep the policy working

Setting the limits is only the start. Someone still needs to review what happens next.

Finance can see where paid usage is limited. Business owners can see which costs they own. Engineering leaders can see where exceptions protect important work. Included-pool controls protect shared credits, organization and cost-center budgets limit additional paid usage, and per-user budgets set individual limits.

Assign someone to review alerts, blocked requests, approved exceptions, and business results on a regular schedule. When a team repeatedly reaches its limit, that owner can look for waste, compare usage with results, and recommend a change. Finance and engineering leaders can then approve the change or step in when cost and delivery needs conflict.

With those responsibilities clear, finance can see the cost, business leaders can own it, and administrators can adjust the controls before the next surprise bill arrives.

A quick reference to the controls

The story above introduces each control when it becomes useful. This table collects the technical differences in one place for reference.

Control	What it does	What it counts	What happens at the limit
Organization or cost-center budget	Monitors or limits shared paid usage	Additional paid usage after included credits are used; license costs are excluded	Sends alerts, or stops affected paid usage when stopping is enabled
Included AI credit pool	Protects the credits included with licenses assigned to a cost center	Shared included AI credits calculated by GitHub	Blocks more AI-credit use, or allows paid usage when paid usage is enabled
Per-user budget	Limits one person's total AI-credit use	Included and paid AI credits for that user	Always stops more affected usage

When an included AI credit pool runs out, administrators can block further AI-credit use or allow it to continue as paid usage, as long as paid usage is enabled. Some reductions to the pool take effect in the next billing cycle, so check the timing before relying on a lower limit.

Learn more

Getting started with GitHub Copilot part 2, streamable responses

Chris Noring — Mon, 16 Mar 2026 20:14:28 +0000

I'm sure you've seen many AI apps where you sit tight for 30s or and you wonder if things are stuck? Not a great experience right? Yes, you're right, you deserve better, so how do we fix it?

Type your prompt> Tell me a joke
.
.
.
.
.
.
.
.
Why could I never find the atoms, cause they split..

Series on Copilot SDK

This series is about Copilot SDK and how you can leverage your existing GitHub Copilot license to integrate AI into your apps

Part 1 - install and your first app
Part 2 - streamable response, you're here

Addressing the problem

By streaming the response, the response now arrives in chunks, pieces that you can show as soon as they arrive. How can we do that though and how can GitHub Copilot SDK help out?

Well, there's two things you need to do:

Enable streaming. You need to set streaming to True when you call create_session.
Listen for events that contains a chunk. Specifically, you need to listen to ASSISTANT_MESSAGE_DELTA and print out the chunk.

# 1. Enable streaming
session = await client.create_session({
        "model": "gpt-4.1",
        "on_permission_request": PermissionHandler.approve_all,
        "streaming": True,
    })

print("Starting streamed response:")

# Listen for response chunks
def handle_event(event):
    if event.type == SessionEventType.ASSISTANT_MESSAGE_DELTA:
        // 2. Chunk arrived, print it
        sys.stdout.write(event.data.delta_content)
        sys.stdout.flush()
    if event.type == SessionEventType.SESSION_IDLE:
        print()  # New line when done

Here's what the full application looks like:

import asyncio
import sys
from copilot import CopilotClient, PermissionHandler
from copilot.generated.session_events import SessionEventType

async def main():
    client = CopilotClient()
    await client.start()

    session = await client.create_session({
        "model": "gpt-4.1",
        "on_permission_request": PermissionHandler.approve_all,
        "streaming": True,
    })

    print("Starting streamed response:")

    # Listen for response chunks
    def handle_event(event):
        if event.type == SessionEventType.ASSISTANT_MESSAGE_DELTA:
            sys.stdout.write(event.data.delta_content)
            sys.stdout.flush()
        if event.type == SessionEventType.SESSION_IDLE:
            print()  # New line when done

    session.on(handle_event)

    print("Sending prompt...")
    await session.send_and_wait({"prompt": "Tell me a short joke"})

    await client.stop()

if __name__ == "__main__":
    asyncio.run(main())

That's it folks, now go out and build better experiences for your users.

Don't miss this opportunity to learn more about GitHub Copilot CLI

Chris Noring — Sun, 08 Mar 2026 22:24:48 +0000

Renee Noble for Microsoft Azure

Mar 5

Get started with GitHub Copilot CLI: A free, hands-on course

#githubcopilot #cli #vscode #terminal

4 min read

Get started with GitHub Copilot SDK, part 1

Chris Noring — Wed, 04 Mar 2026 20:48:00 +0000

Did you know GitHub Copilot now has an SDK and that you can leverage your existing license to build AI integrations into your app? No, well I hope I have you attention now.

Series on Copilot SDK

This series is about Copilot SDK and how you can leverage your existing GitHub Copilot license to integrate AI into your apps

Part 1 - install and your first app, you're here
Part 2 - streamable responses

Install

You need two pieces here to get started:

GitHub Copilot CLI
A supported runtime, which at present means either Node.js, .NET, Python or Go

Then you need to install the SDK for your chosen runtime like so:

pip install github-copilot-sdk

The parts

So what do you need to know to get started? There are three concepts:

Client, you need to create and instance of it. Additionally you need to start and stop it when you're done with it.
Session. The session takes an object where you can set things like model, system prompt and more. Also, the session is what you talk when you want to carry out a request.
Response. The response contains your LLM response.

Below is an example program using these three concepts. As you can see we choose "gpt-4.1" as model but this can be changed. See also how we pass the prompt to the function send_and_wait.

import asyncio
from copilot import CopilotClient

async def main():
    client = CopilotClient()
    await client.start()

    session = await client.create_session({"model": "gpt-4.1"})
    response = await session.send_and_wait({"prompt": "What is 2 + 2?"})

    print(response.data.content)

    await client.stop()

asyncio.run(main())

Ok, now that we know what a simple program looks like, let's make something interesting, an FAQ responder.

Your first app

An FAQ for a web page, is often a pretty boring read. A way to make that more interesting for the end user is if they can instead chat with the FAQ, let's make that happen.

Here's the plan:

Define a static FAQ
Add the FAQ as part of the prompt.
Make a request to to the LLM and print out the response.

Let's build out the code little by little. First, let's define the FAQ information.

-1- FAQ information

# faq.py

faq = {
  "warranty": "Our products come with a 1-year warranty covering manufacturing defects. Please contact our support team for assistance.",
  "return_policy": "We offer a 30-day return policy for unused products in their original packaging. To initiate a return, please visit our returns page and follow the instructions.",     
  "shipping": "We offer free standard shipping on all orders over $50. Expedited shipping options are available at checkout for an additional fee.",
}

Next, let's add the call to the Copilot SDK

-2 Adding the LLM call


import asyncio
from copilot import CopilotClient

def faq_to_string(faq: dict) -> str:
    return "\n".join([f"{key}: {value}" for key, value in faq.items()])

async def main(user_prompt: str = "Tell me about shipping"):
    client = CopilotClient()
    await client.start()

    prompt = f"Here's the FAQ, {faq_to_string(faq)}\n\nUser question: {user_prompt}\nAnswer:"   

    session = await client.create_session({"model": "gpt-4.1"})
    response = await session.send_and_wait({"prompt": prompt})

    print(response.data.content)

    await client.stop()

if __name__ == "__main__":
    print("My first app using the GitHub Copilot SDK!")
    print(f"[LOG] Asking the model about shipping information...")
    asyncio.run(main("Tell me about shipping"))

Note how we concatenate the FAQ data with the user's prompt:

 prompt = f"Here's the FAQ, {faq_to_string(faq)}\n\nUser question: {user_prompt}\nAnswer:"

-3- Let's run it

Now run it:

uv run faq.py

You should see output like so:

My first app using the GitHub Copilot SDK!
[LOG] Asking the model about shipping information...
We offer free standard shipping on all orders over $50. Expedited shipping options are available at checkout for an additional fee.

What's next

Check out the official docs

How YOU can build a Web API in Java and Spring boot

Chris Noring — Tue, 06 Dec 2022 21:49:02 +0000

Build a Web API in Java and Spring boot

In this article you will learn to:

Configure your Visual Studio code environment for usage with Spring Boot.
Create a Spring boot project.
Learn how Spring enables you to create a REST API.
Document your API via Swagger and Open API specification.

Prereqs

You should have the following installed:

Java
Maven, a building tool for building projects and maintaining dependencies
Visual Studio Code

Configure Visual Studio via extensions

To make it easier to work with development of Web APIs in Java, you can install a set of extensions. These extensions will help you with tooling support around auto completion but also stopping starting and debugging your web apps.

You need these two extensions:

which will install the following:

Java development kit JDK
Extension Pack for Java
Spring Boot Extension Pack, specific tooling around using Spring Boot.

To learn more on developing with Java using Visual Studio Code, go to:

https://code.visualstudio.com/docs/java/java-spring-boot

Exercise: Create a Spring boot project

Once you've installed the extensions needed you can use the command palette in Visual Studio Code to scaffold your Spring Boot project.

Bring up the command pallette (View -> Command Palette) and choose the following command:
```
Spring Initializr: Create a Maven Project
```
Specify a Spring Boot version, select 3.0
Specify a project language Java
Input group id for your project com.example, it will scaffold up a directory structure for you as well as adding this id in the pom.xml file.
Input Artifact Id for your project Demo
Specify packaging type Jar, you can change this later to War if you want (if you want to run your app in application server like Tomcat for example, you want a War file but for now the app will run in a built-in server)
Specify Java version
Search for dependencies, you want to add Spring Web at minimum, but might want to add other dependencies in the future like JPA, Session management and more.

Your project so far

This scaffolded a project for you. Let's go through the parts you need to know about:

src/
  main/
    java/
      com/
        example/
          demo/
            DemoApplication.java
    resources/
      application.properties 
  test/

As you can see above, you have structure consisting of application files, DemoApplication.java under demo/, configuration files under resoruces/ and tests under test/.

Application files

So far, you only have one application file DemoApplication.java which looks like so:

package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class Demo2Application {

    public static void main(String[] args) {
        SpringApplication.run(Demo2Application.class, args);
    }

}

This file is the entry point to your application.

Configuration

You have a configuration file application.properties that starting out is empty but will be used as you add things to your app in need of configuring for example:

what port to start up on.
if you got self documenting docs like Swagger.
credentials for a database, if you're using one.

What are routes?

In a Web API there are logical areas of your application like customers, orders, products and so on. When you have the user use your app you can send the user to these logical areas by specifying routes, parts of the URL. Imagine that you have the following URL http://contoso.com and you have three areas in your app:

customers, this is where you handle customers, adding new ones and updating existing ones.
products, these are products the customers can buy.
orders, these are orders the customers can place.

based on these areas, we can now create areas of our app addressing them like so:

/customers
/products
orders

so when a user then navigates to for example /customers they would type in the full address http://www.contoso.com/customers but the route part would be /customers a sub part of the URL.

We can now write code that responds to a route like the ones mentioned above.

Adding a route

To add a route, you need to create a class like so:

@RestController
public class HelloServiceController {
    @RequestMapping(value = "/hello", method = RequestMethod.GET)
    public ResponseEntity<Object> getHello() {
       return new ResponseEntity<>("hello", HttpStatus.OK);
    }
}

Let's break down what's going on:

The decorator @RestController ensures the class can respond to web request.
@RequestMapping(value = "/hello", method = RequestMethod.GET) does two things, response to a specific route "/hello" and to a specific HTTP verb, GET, which means to read data from the server.
The method getHello() produces a response of type ResponseEntity<Object> and the specific call we make, return new ResponseEntity<>("hello", HttpStatus.OK) produces a text response with code 200, HttpStatus.OK which means everything is ok.

Now that we know how we can create code to respond to route requests, let's add code to handle /products route in the below exercise.

Exercise: adding a route

Create a product directory in the same place as your DemoApplication.java file and create the following files:

   Product.java
   ProductController.java
   ProductRepository.java

Give Product.java the following content:

   package com.example.demo.product;

    public class Product 
    {
        private String name;

        public Product(String name) 
        {
            this.name = name;
        }

        public String getName() 
        {
            return this.name;
        }
    }

the Product class will serve as our model.

Give ProductRepository.java the following content:

   package com.example.demo.product;

    import java.util.ArrayList;

    public class ProductRepository 
    {
      private ArrayList<Product> products;

      public ProductRepository() 
      {
        this.products = new ArrayList<Product>();
        this.products.add(new Product("tomato")); 
      }
      public ArrayList<Product> getProducts() 
      {
        return this.products;
      }
    }

ProductRepository will now have one entry of type Product.

Give ProductController.java the following content:

    package com.example.demo.product;
    import org.springframework.http.HttpStatus;
    import org.springframework.http.ResponseEntity;
    import org.springframework.web.bind.annotation.RequestMapping;
    import org.springframework.web.bind.annotation.RestController;

    import java.util.ArrayList;

    @RestController
    public class ProductController {
        /**
         * @return
         */
        // TODO: query param, route param
        @RequestMapping(value = "/products")
        public ResponseEntity<ArrayList<Product>> getProducts() {
           ProductRepository repo = new ProductRepository(); 
           return new ResponseEntity<>(repo.getProducts(), HttpStatus.OK);
        }
    }

Now we have all the code needed to respond to a web request to /products. Next, let's run our app:

Select "Spring Boot dashboard" icon on the left menu in Visual Studio Code, should look like a stop icon.
Select the play icon to start your app
In your browser, navigate to "http://localhost:8080/products", you should see the following output:

   http://localhost:8080/products

Document your API via Open API (Swagger)

Next, we want to learn how to document our API. We can use Open API to do so (formerly known as Swagger). In our pom.xml file, the file Maven uses to keep track of dependencies, we can add the following dependency:

<dependency>
    <groupId>org.springdoc</groupId>
    <artifactId>springdoc-openapi-starter-webmvc-ui</artifactId>
    <version>2.0.0</version>
</dependency>

this will ensure our Maven project knows how to add the capability that will give us Open API support.

On the command line, you can now type:

mvn package

which will fetch all dependencies (if not fetched already) and add package your project into a Jar file.

Open API

This dependency will do two things for us:

Create an Open API specification, a JSON file that describes our API, that can be used to create a connector for Microsoft Power Platform for example or in other ways help describe how to work with our API.
Create a a UI that we can interact with to test our interface.

Exercise: add Open API

Add the following XML to the dependencies section of your pom.xml:

   <dependency>
    <groupId>org.springdoc</groupId>
    <artifactId>springdoc-openapi-starter-webmvc-ui</artifactId>
    <version>2.0.0</version>
   </dependency>

Run mvn package in the command line
In resources directory, locate application.properties and add the following content:

   springdoc.api-docs.path=/docs
   springdoc.swagger-ui.path=/swagger.html

this will ensure we can find our Open API spec file at /docs and our UI at swagger.html

Start the app again via the Spring boot dashboard icon in Visual Studio Code:
Navigate to "http://localhost:8080/docs", you should see a JSON output similar to below, i.e our specification file:

   {"openapi":"3.0.1",
    "info":{"title":"OpenAPI definition","version":"v0"},"servers":[
      { "url":"http://localhost:8080",
        "description":"Generated server url"}],
        "paths":{
          "/hello":{"get":{
          "tags":["hello-service-controller"],"operationId":"getHello",
          "responses":{
            "200":{
              "description":"OK",
              "content":{
                "*/*":{"schema":{"type":"object"}}}}}
         }},
         "/products":{
                  "get":{"tags":["product-controller"],    "operationId":"getProducts",
                  "responses":{"200":{"description":"OK","content":{"*/*":{"schema":{"type":"array","items":{"$ref":"#/components/schemas/Product"}}}}}}},
                  "put":{"tags":["product-controller"],"operationId":"getProducts_3",
                  "responses":{"200":{"description":"OK","content":{"*/*":{"schema":{"type":"array","items":{"$ref":"#/components/schemas/Product"}}}}}}},
                  "post":{"tags":["product-controller"],"operationId":"getProducts_2",
                  "responses":{"200":{"description":"OK","content":{"*/*":{"schema":{"type":"array","items":{"$ref":"#/components/schemas/Product"}}}}}}},
                  "delete":{"tags":["product-controller"],"operationId":"getProducts_5",
                  "responses":{"200":{"description":"OK","content":{"*/*":{"schema":{"type":"array","items":{"$ref":"#/components/schemas/Product"}}}}}}},
                  "options":{"tags":["product-controller"],"operationId":"getProducts_6",
                  "responses":{"200":{"description":"OK","content":{"*/*":{"schema":{"type":"array","items":{"$ref":"#/components/schemas/Product"}}}}}}},
                  "head":{"tags":["product-controller"],"operationId":"getProducts_1",
                  "responses":{"200":{"description":"OK","content":{"*/*":{"schema":{"type":"array","items":{"$ref":"#/components/schemas/Product"}}}}}}},
                  "patch":{"tags":["product-controller"],"operationId":"getProducts_4",
                  "responses":{"200":{"description":"OK","content":{"*/*":{"schema":{"type":"array","items":{"$ref":"#/components/schemas/Product"}}}}}}}}},
                  "components":{"schemas":{"Product":{"type":"object","properties":{"name":{"type":"string"}}}}}}

Navigate to http://localhost:8080/swagger.html this will present you with a graphical view, where you can try out your API.

Congrats, you've managed to build a Web API support the route /products but you also managed to document it using Open API. You are know well setup do extend it further and add data source to it with for example JPA (Java Persistence API), which we will cover in our next article.

Go from the beginning - arrays and slices

Chris Noring — Tue, 27 Sep 2022 16:41:52 +0000

An array is group of elements that are connected. You want to use an array when you have a group of something, like many orders, cars, rows in a file. The idea is to collect all that data in one structure. You also want to be able to iterate over it and possibly carry out an operation on it as a group.

Series

Your first program, you are here
Variables
If and else
Conversions
Loops
User input
Functions
Error handling
Arrays, you are here

Declare an array

To declare an array, you need to specify the following properties:

capacity, how many elements it holds.
type, what type of elements it holds.
array content, you can assign it elements at creation or do so later.

Here's the syntax:

[<capacity>]<type>{...element}

It starts with the square brackets, []. Within the square brackets you set the capacity, how many elements it can hold.

and here's a more real example:

cities := [5]string{"NY", "LA"}

In the preceding code, an array of strings is declared. It has capacity for 5 elements and two of the places are filled with "NY" and "LA". Note also because we set the capacity to 5 and the number of elements it's assigned is 2, there's 3 spaces free.

Capacity by inference

You don't have to set capacity to an explicit number, you can set it to ..., in which case the capacity will be set to the number of elements you assign to it, like so:

ids := [...]int{1, 2, 3, 4}

The preceding code has 4 elements, and that's also its capacity.

Accessing elements

The way to access an element is by using its index. Index is 0 based, meaning the first index is 0 and its last is the length -1.

ids := [...]int{1, 2, 3, 4}
ids[0] // 1
ids[3] // 4

Length and capacity

Imagine we have the following array declared:

cities := [5]string{"NY", "LA"}

length. The length is defined as the number of elements in the array. You can use the len() method to find this out:

   len(cities) // 2

capacity. The capacity is how many elements the array can hold. cap() is the method you use to find the capacity:

   cap(cities) // 5

Slices

A slice is a part of an array. A slice is created when the slice operator is being used. Here's the syntax for the slice operator:

s[i:p]

s, the array
i, the first index of the array to take elements from
p, The variable p corresponds to the last element in the underlying array that can be used in the new slice. I.e cut right before this index.

items := [5]int{1,2,3,4,5}
part = items[1:3] // 2,3

Adding elements

A slice differs from an array, you can add items to it. The append() method lets you add elements to it. The syntax for append() is as follows:

append(slice, element)

Here's how you can append to a slice:

var numbers []int
numbers = append(numbers, 1)
numbers = append(numbers, 2) // 1,2

Removing elements

Remove an element by constructing a new slice.

letters := []string{"A", "B", "C", "D", "E"}
remove := 2 // remove index
// 0 - remove index, remove +1 to end   
letters = append(letters[:remove], letters[remove+1:]...)

Create a slice with make

You can use the make() method to create a slice. Here's how:

slice := make([]int, 5) // creates a slice with length 5 and capacity 5

You can set these to different values:

slice2 := make([]int, 2, 5)
fmt.Println(slice2)
fmt.Println(len(slice2))
fmt.Println(cap(slice2))

Here, the slice has length 2 and capacity 5.

Copy elements

arr := [3]int{1, 2, 3}
dest := make([]int, 5)
copy(dest, arr[0:2]) // copies slice {1,2} into dest
fmt.Println(dest) // [1 2 0 0 0]

Summary

In summary, you were taught how to use Arrays. Additionally, we covered working with slices. Slices allows you to work with an array like structure and change its size as you see fit.

Learn more

https://docs.microsoft.com/en-us/learn/modules/go-data-types/2-slices

How YOU can deploy your resume in 2 min using Azure Static Web apps

Chris Noring — Tue, 20 Sep 2022 15:54:26 +0000

TLDR; In this post, you'll deploy your resume to the cloud using Visual Studio Code and Azure Static Web Apps.

Resources

Creating your resume

Writing a resume is an important activity in landing your first job as a student. It's also important later in life for those times you're looking to grow in your career.

Azure Static Web apps

Azure Static Web Apps is an Azure service that lets you deploy simpler static sites as well as web apps built in a SPA framework. It even lets you add an API to build a fullstack app.

In short, there's a great grow up story.

Tools for deployment and app lifecycle

Azure Static Web apps lets you deploy using more than one way, you can use of any of the following approaches:

How it works

Azure Static Web apps does more for you than just deployment. In fact, it handles the complete app dev lifecycle. The first time you deploy, it creates a CI/CD pipeline so that any future changes, you only need to focus on pushing commits to GitHub. The rest, to redeploy, is all taken care of by a .yml file created in a .github directory in you repo. High-level, here's what's going on:

Deploy the first time

Project deployed.
.yml file created in repo creating a CI/CD pipeline.
GitHub actions deploying everything using the .yml file above.

Future changes

You push commits to your repo
Everything is built and deployed using GH actions and your .yml file.

Deploy your resume

To deploy our resume, we need the following software installed.

Prerequisites

To deploy our resume, we need the following:

A GitHub account and we need to be logged in.
Visual Studio Code installed.
Azure Static Web Apps and VS Code extension installed.

Deployment

In this deployment, you can definitely create your own resume and repo or create one from this template.

If you start with static files (not from a GH repo), you will get some questions below regarding Git.

Type (Command + P or Control P) to open the command palette.
Type "Azure Static Web Apps: Create Static Web App" to start the deployment process.
Select your subscription
Select "Create" when asked to create a Git repo as well as GH repo (if you start with only static files, if you start from a repo, you won't get this question)
Enter a commit message, you can select what it proposes, i.e "Initial commit"
Enter name of static web app
Enter name of GH repository (it will be created for you)
Select a region
Select "Custom" as preset
Enter location of application /
Enter location of build output, clear this field.

From here, it should be deploying your project - Congrats, your resume is online

Summary

You learned how you can deploy your resume in minutes using Azure Static Web Apps and Visual Studio Code.

How YOU can build your own test framework in Python using decorators

Chris Noring — Wed, 31 Aug 2022 14:33:36 +0000

TLDR; this article will show how decorators work, some uses for decorators and a bigger example building the start of test framework. It's ~15 min long BUT, there's a very cool project at the end of it - learning how to build your own test framework :)

So, decorators, what are those, and why would I use them? You might have seen something like this before in your Python code @debug or @log right above your function signature like so:



@log
def method():
  pass

Running your method, you might have gotten out some useful information about the method(). If you haven't seen this, that's fine, let me take you on a journey.

References

Decorators

The @ character denotes something we call decorators; the idea is to decorate a function without the function being aware. It can add capabilities to the function like:

execution time, how long it takes the function to run from start to finish.
debugging, information on function name, parameters.

Let's look at a case where we decorate a function:



def decorator(fn):
  print("BEFORE")
  fn()
  print("AFTER")

def log():
  print("[LOG]")

decorator(log)

Running this function results in the following output:



BEFORE
[LOG]
AFTER

Python decorators

Python has a specific way of handling decorators, so much so it lets you use a shorthand @. But first, let's tweak the above code so that it's a good candidate to using the shorthand. Change the code to the following:



def decorator(fn):
  def wrapper()
    print("BEFORE")
    fn()
    print("AFTER")
  return wrapper

def log():
  print("[LOG]")

fn = decorator(log)

What we did was to create an inner function wrapper() in decorator() function and return it. Also, when invoking decorator(), we save the response to fn and invoke that:



fn = decorator(log)

Here's the beautiful part, Python lets us turn the above code:



def log():
  print("[LOG]")

fn = decorator(log)

and turn it into the following:



@decorator
def log():
  print("[LOG]")

log()

Note above how @decorator have replaced the call to decorator() and @decorator is now above the definition of log().

Pause here for a moment and take this in. This is a great start!

Parameters

OK, so great progress so far, we can write decorators, but what happens if we want to use parameters on functions being decorated? Well, let's see what happens:



@decorator
def add(lhs, rhs):
  return lhs + rhs

add(1,1)

You get an error:



TypeError: wrapper() takes 0 positional arguments but 2 were given

So, we're not handling incoming parameters, how to fix?

Well, when you call a function, there are two parameters that Python works with under the hood:

*args, a list of parameter values.
**kwargs, a list of tuples where each tuple is the name and value of your parameter.

You can fix the above issue if you send these via your wrapper function into the function being decorated like so:



def wrapper(*args, **kwargs):
    fn(*args, **kwargs)
  return wrapper

Running the code again, it compiles this time, but the output says None, so there seems to be some other problem, where we lose the return value of our decorated function.

How can we solve that?

What we need to do is to ensure the wrapper() function captures the return value from the function being decorated and return that in turn, like so:



def wrapper(*args, **kwargs):
    ret = fn(*args, **kwargs)
    return ret
  return wrapper

Great, so we learned a little more about dealing with parameters and return values with decorators. Let's learn next how we can find out more about the function we decorate.

Instrumentation

We're building up our knowledge steadily so we're able to use it to build a bigger project at the end of the article. Now let's look at how we can find out more about the function we decorate. In Python, you can inspect and find out more about a function by using the help() method. If you only want to find out a functions' name, you can refer to __name__ property like so:



def log():
  print("[LOG]")

print(log.__name__) # prints log

How does this work in a decorator, is there a difference?

Let's try it by adding it to the decorator:



def decorator(fn):
  def wrapper(*args, **kwargs):
    print("calling function: ", fn.__name__)
    ret = fn(*args, **kwargs)
    return ret
  return wrapper

@decorator
def add(lhs, rhs):
  return lhs + rhs

print(add.__name__)
print(add(1,1))

Calling the above code, we get the following output:



wrapper
calling function:  add
2

It seems, add() within the decorator is rightly referred to as add. However, outside of the decorator calling add.__name__, it goes by wrapper, it seems confused, no?

We can fix this using a library called functools that will preserve the function's information like so:



@functools.wraps(fn)

and our full code now looks like:



import functools

def decorator(fn):
  @functools.wraps(fn)
  def wrapper(*args, **kwargs):
    print("calling function: ", fn.__name__)
    ret = fn(*args, **kwargs)
    return ret
  return wrapper

@decorator
def add(lhs, rhs):
  return lhs + rhs

print(add.__name__)
print(add(1,1))

Running this code, we see that it's no longer confused and the add() function is referred to as add in both places.

Ok, we know enough about decorators at this point to be dangerous, let's build something fun, a test framework.

Assignment - build a test framework

DISCLAIMER: I should say there are many test frameworks out there for Python. This is an attempt to put you decoration skills into work, not to add to an existing pile of excellent frameworks, however, you're free to hack away at this project if you find it useful :)

-1- How should it work

Ok, let's start with how it should work, that will drive the architecture and the design.

We want to have the following experience as developers writing tests:

I just want to add a @test decorator.
I want to call some type of assertion in my test methods.
I want to do max one function call to run all tests.
I want to see tests that succeed and fail, and I want extra info about the failing test so I can correct it
Nice to have, please add color to the terminal output.

Based on the above, my test file should look something like this:



@test
def testAddShouldSucceed():
  lhs = 1
  rhs = 1
  expected = 2
  expect(add(lhs,rhs), expected, "{lhs} + {rhs} should be equal to {sum}".format(lhs = lhs, rhs = rhs,sum = expected))

@test
def testAddShouldSucceed2():
  lhs = -1
  rhs = 1
  expected = 0
  expect(add(lhs,rhs), expected, "{lhs} + {rhs} should be equal to {sum}".format(lhs = lhs, rhs = rhs,sum = expected))

if __name__ == "__main__":
  run()

-2- Building the parts, `decorator()`, `expect()`

Ok, based on the previous part, we need three things:

@test, a decorator.
expect() a method that checks if two values are equal.
run() a method running all functions decorated with @test.

Let's get to work.

Create a file decorator.py and give it the following content:



   def test(fn):
      @functools.wraps(fn)
      def wrapper(*args, **kwargs):
        try:
          fn(*args,**kwargs)
          print(". PASS") 
        except TestError as te:
          print(f"{fn.__name__} FAILED with message: '{te.mess}'")
        # fns.append(wrapper)
      return wrapper

The above decorator test() will run test method and print . PASS if the method runs without error. However, if TestError is thrown, you will see FAILED with message . How can a test method crash? Let's implement expect() next.

Create a file expect.py and give it the following code:



   from util import TestError

   def expect(lhs, rhs, mess):
     if(lhs == rhs):
       return True
     else:
       raise TestError(mess)

Ok, so return true if all good, and crash if not, got it!. What is TestError?

Create a file util.py and give it the following code:



   class TestError(Exception):
     def __init__(self, mess):
       self.mess = mess

Above we're inheriting from Exception and we'e adding a field mess that we store any error message in.

Let's revisit decorator.py. Look at the following codeline:



   def test(fn):
      @functools.wraps(fn)
      def wrapper(*args, **kwargs):
        try:
          fn(*args,**kwargs)
          print(". PASS") 
        except TestError as te:
          print(f"{fn.__name__} FAILED with message: '{te.mess}'")
        # fns.append(wrapper)
      return wrapper

Enable the commented out line # fns.append(wrapper). What this line does is to add each test function to a list. We can use that when we implement the run() function. Add run() to the bottom of the file with this code:



   def run():
     for fn in fns:
       fn()

Great, now we just have one thing missing, some colors :)

-3- Give it color

To give it colors let's install a library coloroma.

Create a virtual environment



   python3 -m venv test-env

Activate the virtual environment



   source test-env/bin/activate

Install colorama



   pip install colorama

Adjust decorator.py and ensure the code looks like so:



   import functools

   from colorama import Fore
   from colorama import Style
   from util import TestError

   fns = []

   def test(fn):
     @functools.wraps(fn)
       def wrapper(*args, **kwargs):
         try:
           fn(*args,**kwargs)
           print(f"{Fore.GREEN}. PASS{Style.RESET_ALL}")
         except TestError as te:
           print(f"{Fore.RED}{fn.**name**} FAILED with message: '{te.mess}' {Style.RESET_ALL}")
       fns.append(wrapper)
       return wrapper

    def run():
      for fn in fns:
        fn()

Create a file demo.py and give it the following content:



   from decorator import test, run
   from expect import expect

   def add(lhs, rhs):
     return lhs + rhs

   @test
   def testAddShouldSucceed():
     lhs = 1
     rhs = 1
     expected = 2
     expect(add(lhs,rhs), expected, "{lhs} + {rhs} should be equal to {sum}".format(lhs = lhs, rhs = rhs,sum = expected))

   @test
   def testAddShouldSucceed2():
     lhs = -1
     rhs = 1
     expected = 0
     expect(add(lhs,rhs), expected, "{lhs} + {rhs} should be equal to {sum}".format(lhs = lhs, rhs = rhs,sum = expected))

   @test
   def testAddShouldFail():
     lhs = 1
     rhs = 2
     expected = 4
     expect(add(lhs,rhs), expected, "{lhs} + {rhs} should be equal to {sum}".format(lhs = lhs, rhs = rhs,sum = expected))

   if **name** == "**main**":
     run()

-4- Demo time

Run the program



   python demo.py

Congrats, you've built your first test framework.

Ideas for improvement

So, what's next?

Well, the expect() method is limited in what it can compare, see if you can build other functions capable of comparing lists, objects and so on. Also, how would you test if a method throws a specific exception?

Summary

You've learned about decorators and their use cases. You've also built something useful with them - a test framework. Try it out, change it to your liking. Also, I would recommend reading this excellent post as well, https://realpython.com/primer-on-python-decorators/

How YOU can build your first Low code app using Microsoft Power Platform

Chris Noring — Mon, 08 Aug 2022 13:34:32 +0000

TLDR; in this article, you will learn how to build your first Low Code application using Power platform.

You will learn:

Lay out controls for displaying and capturing data.
Respond to events.
Save state in a variable.

References

What is Low code and why do we care?

Low code development is using blocks instead of specific code to build apps and services. There are many Low Code platforms, Microsoft's is called Microsoft Power Platform.

The reason these platforms exist is that there's a great need to build business apps and not enough developers to build them. Also, many times non developer sit on business expertise, and it takes time to convey all they know to developers.

With a low code platform, you can empower these business experts and turn them into citizen developers, and have them build apps.

Canvas app

There are many types of low code apps you can build with Microsoft Power Platform. Canvas apps lets you build traditional apps in many ways.

You can either build everything from scratch or model driven from a data source like for example Dataverse.

The idea is that you design an app much like a Powerpoint slide and use Excel like expressions to add logic.

DEMO - build your first app

Navigate to https://make.powerapps.com
Select "+ Create", to create a canvas app.
Select "Blank app", in the main area on your right.
Give it an app name and select Tablet.
Select + in the left menu to add controls.
Select a Text label and drag it onto the screen.
Select the control and change the Text property, either in the control or via the dropdown like so:

Select a button and drag it onto the screen. Change its value to "Save".
Select the button and ensure the OnSelect property is selected.
Change the fx value to UpdateContext({ myvar: "clicked" }), this will create a variable myvar and give it the value "clicked":

Select your label and change its content, in the fx area, to the following "Show text:" & myvar, this will ensure it shows the content of a static text and the value of myvar.

The & concatenates two strings together.

Test your program by clicking the play icon on the top right side:

Try clicking the button and ensure it says "clicked".

Nicely done, you've created your first Canvas app, but we can improve it a little by relying on text inputs.

Use a text field

Drag a Text input out onto the main surface.
Note the name of the Text Input, you will refer to it now in the OnSelect property of the button:

Change the OnSelect fx value of the button to the following code

   UpdateContext({ myvar: TextInput2.Text })

The above code will set myvar to the content of the TextInput2 control and its Text property.

Run your program:
1. Enter some text, for example "abc" in the text field
2. Click the button, you should now see the label be updated accordingly to "Show text: abc", it's working.

Let's improve our program next by clearing the input field after we click a button.

Clear input fields

Select the button and add the following code in the fx area:

   Reset(TextInput2)

Your full code in OnSelect should look like so:

   UpdateContext({ myvar: TextInput2.Text });

   Reset(TextInput2);

Drag the fx field down vertically to see more of it. Note how we added semicolons, ; above to separate between multiple statements.

this code will clear the text input field and reset it to its default value.

You were show one way so far to clear a text input, there's another way, lets do that next.

Select the text input field and find a property in the control detail on the right called "Clear button" and enable it, like so:

Run the program and notice the "X" that appears in the text field. This "X" will let you clear the text field via the UI.

Congratulations, you've taken your first steps to using controls and understand how they work.

Interview problem - FizzBuzz

Chris Noring — Wed, 06 Jul 2022 21:35:00 +0000

So, you try to pass an interview as a programmer. There are a few ways you're tested, it's not just coding skills but your ability to communicate.

Communicate, what do you mean, code either compiles and works or it don't?

Well, no, so you live in a world with stakeholder and team members. In that world, you need to navigate and that means understanding a problem, asking clarifying questions and be prepared for changes and yes sometimes short deadlines.

So what can I expect on the interview then?

Well, for one, a problem, and not just a problem, you're expected to communicate from start to finish, through all the phases.

What phases?

Understand the problem

In this phase, you need to listen, repeat back what you heard and from there communicate assumptions. If those assumptions are incorrect, you may get clarifications. What you don't want to do is to just code away thinking you understood everything.

Problem breakdown

In this phase, you should start to think about how to break down a problem in easier parts, sub problems if you will. At the job, you will be given big and complicated tasks and you will be asked to break it down into smaller parts that you can solve. - That's the job, oh and coding :).

Start coding

At this point, start implementing the easier parts of your problem, a naive solution if you will. See if your interviewer has any comments. Then proceed until you have a working solution.

Cover all your bases

At this point, ensure you communicate any edge cases that you might need to handle and possible improvements to your code.

Here it's likely your interviewer may spot a bug or ask you to implement a new requirement. Don't panic, take your time and figure out how to solve.

Summary

In the last part, the interviewer may sum up the interview and ask general questions, but if you have communicated thus far, you've written reasonable code that mostly works, chances are you pass this interview.

So what problem am I likely to get, can you give m an example?

The problem : Fizz Buzz

Lets take a problem called Fizz Buzz. Here's the description:

Your code is divisible by 5 and 3. If both then print "FizzBuzz", if only by 3, then "Fizz" if only by 5, then "Buzz".

To approach this problem, ensure you understand its sub problems:

1) Divisible, that a number is divided and leaves no remainder and you at least in Python have a module operator to help you.
2) Understand what condition to implement first, i.e. you should start with divisible by 5 and 3 and then add the other conditions.

Here's a solution:

arr = range(30)
for item in arr:
  no = item + 1
  if no % 5 == 0 and no % 3 == 0:
    print(f"{no} FizzBuzz")
  elif no % 5 == 0:
    print(f"{no}: Buzz")
  elif no %3 == 0:
    print(f"{no} Fizz")
  else:
    print(f"{no}")

and yea, take your time implementing and COMMUNICATE cause you're tested on both skills.

DEV Community: Chris Noring

Understanding GitHub Billing and management: from licenses to fair AI credit controls

Series

Problem 1: A central purchase does not identify who is licensed

Solution: Assign seats to named users

Problem 2: Licensed usage has no business owner

Solution: Use cost centers to establish ownership

Problem 3: One group can consume another group's included credits

Solution: Enable the included usage cap

Problem 4: The included usage cap does not stop overage

Solution for Business: Use a $0 hard budget

Solution for Developers: Start with a soft budget

Problem 5: An aggregate budget does not create individual fairness

Solution: Add a cost-center ULB

Problem 6: One baseline does not fit every role

Solution: Add an individual override

Resolution: See the complete control model

Checkpoint: Avoid the most common misunderstandings

Outcome: Different teams, appropriate controls

GitHub Admin UI + Billing API: Better together for smarter spend decisions

Series

Use each surface for what it does best

The question: Spend is up, but what is driving it?

1. Start in the admin UI: Find the increase

Narrow the increase by organization

Connect the increase to a cost center

2. Continue with the API: Answer the repeatable question

Define the reporting question first

Understand the per-user query pattern

Reveal concentration that totals can hide

3. Return to the admin UI: Choose the right control

Set a cost-center user-level baseline

Preserve justified exceptions

Why the UI and API work better together

Make it part of the operating rhythm

The better-together workflow at a glance

Learn more

Turning surprise AI bills into accountable growth with GitHub Billing Controls

Series

Confusion: The bill is higher than expected

Investigation: Follow the spend

Identify the consumption category

Locate the accountable organization

Connect usage to a cost center

Resolution: Put guardrails in place

Set a boundary for shared paid usage

Create accountable room for a cost center

Give different users the right limits

Explain which user limit takes priority

Aftermath: Keep the policy working

A quick reference to the controls

Learn more

Getting started with GitHub Copilot part 2, streamable responses

Series on Copilot SDK

Addressing the problem

Links

Don't miss this opportunity to learn more about GitHub Copilot CLI

Get started with GitHub Copilot CLI: A free, hands-on course

Get started with GitHub Copilot SDK, part 1

Series on Copilot SDK

Install

The parts

Your first app

What's next

How YOU can build a Web API in Java and Spring boot

Build a Web API in Java and Spring boot

Further reading

Prereqs

Configure Visual Studio via extensions

Exercise: Create a Spring boot project

Your project so far

Application files

Configuration

What are routes?

Adding a route

Exercise: adding a route

Document your API via Open API (Swagger)

Open API

Exercise: add Open API

Go from the beginning - arrays and slices

-2- Building the parts, `decorator()`, `expect()`