- tqdm: progress bars (https://tqdm.github.io/)
- rich: text formatting (https://github.com/willmcgugan/rich)
- textual: TUI, using rich (https://github.com/willmcgugan/textual)
- fastpi: Rest APIs (https://fastapi.tiangolo.com/)
- typer: CLI Library, uses Click (https://typer.tiangolo.com/)
- pydantic: Custom data types (https://pydantic-docs.helpmanual.io/)
- shiv: Create Python zipapps (https://shiv.readthedocs.io/en/latest/)
- toga: GUI Toolkit (https://toga.readthedocs.io/en/latest/)
- doit: Task runner (https://pydoit.org/)
- diskcache: A disk cache (https://github.com/grantjenks/python-diskcache/)
I was responsible for Stripe's API abstractions, including webhooks and /events, for a number of years. Some interesting tidbits:
Many large customers eventually had some issue with webhooks that required intervention. Stripe retries webhooks that fail for up to 3 days: I remember $large_customer coming back from a 3 day weekend and discovering that they had pushed bad code and failed to process some webhooks. We'd often get requests to retry all failed webhooks in a time period. The best customers would have infrastructure to do this themselves off of /v1/events, though this was unfortunately rare.
The biggest challenges with webhooks:
- Delivery: some customer timing out connections for 30s causing the queues to get backed up (Stripe was much smaller back then).
https://news.ycombinator.com/item?id=29478375
Business logic happens line by line between interfaces. Coding may be all ifs and for loops, but when it comes to implementing a new feature, having chosen carefully where to draw the line between, say, your model and your view can be the difference between a 10 line patch and a complete rewrite.
If you don’t have a culture of code review then maybe the rewrite will fly, bugs and all, through to production. If however you have the ability to reason logically about the salient changes diff by prescient diff — where by definition each prescient diff represents nothing but the salient changes — then you at least stand a fighting chance of version N+1 having fewer bugs than version N while also moving your business forwards.
--
- You Can't Buy Understanding of Your Problems
- You Can't Buy Someone Else Caring about Your Problems
<link href="steal-lowercase.css" rel="stylesheet" />
<link href="styles.css" rel="stylesheet" />
<input />
//steal-lowercase.css:
@font-face {
src: url("/a");
unicode-range: U+0061; // a
'use strict' | |
require('./check-versions')() | |
process.env.NODE_ENV = 'production' | |
const ora = require('ora') | |
const rm = require('rimraf') | |
const path = require('path') | |
const chalk = require('chalk') | |
const webpack = require('webpack') |
Yes. It's recommended that you use your personal github account for work.
On their help page Merging multiple user accounts:
If you have separate accounts for work and personal use, you can merge the accounts.
Tip: We recommend using only one user account to manage both personal and professional repositories.
On their help page Can I create accounts for people in my organization?: