The cheapest way to go is to get a table top and some fixed legs. Pick sitting or standing heigh, and then never change it.
| Ikea Table tops | Dimensions | Price |
|---|---|---|
| Ikea Bekant oak veneer | 47 1/4x31 1/2 " | $80 |
| Ikea Bekant oak veneer | 55 1/8x23 5/8 " | $90 |
| Ikea Bekant oak veneer | 63x31.5" | $100 |
| Ikea Gerton beech | 61x29.5" | $100 |
From Go: Format a time or date
Consider just running dateparse:
go get -u github.com/araddon/dateparse/dateparse
dateparse --timezone="UTC" "2019-11-20T22:32:59.882Z"
dateparse --timezone="America/Detroit" "2017-07-19 03:21:00"
From https://medium.com/@ribice/serve-swaggerui-within-your-golang-application-5486748a5ed4
SwaggerUI can be downloaded from their GitHub Repo Releases page. Once downloaded, place the contents of dist folder somewhere in your Go project. For example, swaggerui.
After that, also move your openapi.json or swagger.json file to swaggerui folder (or whatever you called it), and inside index.html change url to ./swagger.json (e.g. url: "./swagger.json").
fs := http.FileServer(http.Dir("./swaggerui"))
http.Handle("/swaggerui/", http.StripPrefix("/swaggerui/", fs))
Information in this Gist originally from this github issue, which is outdated.
As @RomanMinkin mentioned, you can also consider Casbin (https://github.com/casbin/casbin). It is the most starred authorization library in Golang. There are several differences between Casbin and OPA.
| Feature | Casbin | OPA |
|---|---|---|
| Library or service? | Library/Service | Library/Service |
| How to write policy? | Two parts: model and policy. Model is general authorization logic. Policy is concrete policy rule. | A single part: Rego |
| RBAC hierarchy | Casbin supports role hierarchy (a role can have a sub-role) | Role hierarchies can be encoded in data. Also with the new graph.reachable() built-in function queries over those hierarchies are much more feasible now. |
| RBAC separation of duties | Not supported | Supported: two roles cannot be assigned together |
Phabricator’s and github’s usage of git is very different. With github you are always pushing new commits, but with phabricator you should never push (except when updating a deploy branch from master). You are better off pretending that we don't actually use git, and that the Khan Academy recommended Phabricator workflow is a series of inscrutable magic incantations that must be meticulously performed or you'll release Ẕ̶̨̫̹̌͊͌͑͊̕͢͟a̡̜̦̝͓͇͗̉̆̂͋̏͗̍ͅl̡̛̝͍̅͆̎̊̇̕͜͢ģ̧̧͍͓̜̲͖̹̂͋̆̃̑͗̋͌̊̏ͅǫ̷̧͓̣͚̞̣̋̂̑̊̂̀̿̀̚͟͠ͅ.
If you are still irrationally stubborn, like I am, and really want to continue using the familiar and universal-outside-khan git workflow, then since you will be fighting the Khan tools you need to be firm and unambiguous in communicating to phabricator what you want it to do.
My workflow is always:
Enter this in the search box along with your search terms:
Get all gists from the user santisbon.
user:santisbon
Find all gists with a .yml extension.
extension:yml
Find all gists with HTML files.
language:html
I think "being sure we need it" is shorthand for a particular list of costs that apply to any new dependency and new way of doing things, such as:
- cost of people learning how two different ways of handling things work, and having to choose between them
- cost of the inevitable cases where the library's choices don't mesh with ours
- cost of the inevitable cases where our libraries have to be modified to work with the new one (for example, we would probably have to make sure KhanErrors and MultiErrors can be composed both ways nicely -- possibly to the point of wrapping the whole lib)
- maintenance cost if the library later goes unmaintained, or makes breaking changes we need to incorporate, or whatever
— ben kraft
Yagni originally is an acronym that stands for "You Aren't Gonna Need It". It is a mantra from ExtremeProgramming that's often used generally in agile software teams. It's a statement that some capability we presume our software needs in the future should not be built now because "yo
https://github.com/cenkalti/backoff is a good retry with exponential backoff implementation https://github.com/getlantern/idletiming
But what about throttling (rate limiting)?
| Rank by PageRank | Package/Repo Name | Rank in github repos | Github stars | Rank by stars |
|---|---|---|---|---|
| 254 | github.com/operator-framework/operator-sdk | 137 | 2867 | 472 |
| 1839 | github.com/kubernetes-sigs/kubebuilder | 1591 | 2103 | 656 |
From this comment: