Inspired by dannyfritz/commit-message-emoji
See also gitmoji.
Commit type | Emoji |
---|---|
Initial commit | π :tada: |
Version tag | π :bookmark: |
New feature | β¨ :sparkles: |
Bugfix | π :bug: |
Inspired by dannyfritz/commit-message-emoji
See also gitmoji.
Commit type | Emoji |
---|---|
Initial commit | π :tada: |
Version tag | π :bookmark: |
New feature | β¨ :sparkles: |
Bugfix | π :bug: |
--[[ | |
release.luau - A Lune script for publishing Roblox games | |
MPL 2.0 License | |
(c) 2024, Zack Ovits | |
usage: lune run release | |
--]] | |
-- Lune libraries | |
local stdio = require("@lune/stdio") |
import os | |
from typing import Dict, List, Optional | |
import requests | |
from jose import jwt, jwk | |
from jose.utils import base64url_decode | |
JWK = Dict[str, str] | |
JWKS = Dict[str, List[JWK]] |
"""MkDocs hook for performance debugging | |
The idea behind it is to provide a minimal curated performance log for a `mkdocs build` run. | |
Of course anyone can use a proper profiler, but the output often contains a lot of non-critical data | |
that the user has to first filter to get a clearer picture. This hook takes care of this and allows | |
to quickly see where a bottleneck is occurring. It also has a lower overhead than a proper profiler. | |
It creates a file in the current working directory, it can be configured easily with variables set | |
at the bottom of the file. There are also the timing categories included. |
// PLIST in NSData to NSDictionary | |
NSDictionary * result = [NSPropertyListSerialization propertyListWithData:data options:0 format:&format error:outError]; |
Organizing your Go (Golang) project's folder structure can help improve code readability, maintainability, and scalability. While there is no one-size-fits-all structure, here's a common folder structure for a Go project:
project-root/
βββ cmd/
β βββ your-app-name/
β β βββ main.go # Application entry point
β β βββ ... # Other application-specific files
In some cases, only these lines will work
for product in IntelliJIdea WebStorm DataGrip PhpStorm CLion PyCharm GoLand RubyMine; do
rm -rf ~/.config/$product*/eval 2> /dev/null
rm -rf ~/.config/JetBrains/$product*/eval 2> /dev/null
done
But if not, try these
UPDATE: I have baked the ideas in this file inside a Python CLI tool called pyds-cli
. Please find it here: https://github.com/ericmjl/pyds-cli
Having done a number of data projects over the years, and having seen a number of them up on GitHub, I've come to see that there's a wide range in terms of how "readable" a project is. I'd like to share some practices that I have come to adopt in my projects, which I hope will bring some organization to your projects.
Disclaimer: I'm hoping nobody takes this to be "the definitive guide" to organizing a data project; rather, I hope you, the reader, find useful tips that you can adapt to your own projects.
Disclaimer 2: What Iβm writing below is primarily geared towards Python language users. Some ideas may be transferable to other languages; others may not be so. Please feel free to remix whatever you see here!
>>> docker exec -it CONTAINERID /bin/sh
/app # telnet
/bin/sh: telnet: not found
/app # apk update
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.7/community/x86_64/APKINDEX.tar.gz
v3.7.0-243-gf26e75a186 [http://dl-cdn.alpinelinux.org/alpine/v3.7/main]
v3.7.0-229-g087f28e29d [http://dl-cdn.alpinelinux.org/alpine/v3.7/community]