| git_current_branch () { | |
| local ref | |
| ref=$(command git symbolic-ref --quiet HEAD 2> /dev/null) | |
| local ret=$? | |
| if [[ $ret != 0 ]] | |
| then | |
| [[ $ret == 128 ]] && return | |
| ref=$(command git rev-parse --short HEAD 2> /dev/null) || return | |
| fi | |
| echo ${ref#refs/heads/} |
Spring Boot applications can run within a container by Multi-Layer based approach. Each layer may contain different parts of the application such as dependencies, source code, resources and even snapshot dependencies.
In the other hand, with Multi-Stage Build approach, any application can be built at a separate image from the final image that will contain the runnable application.
Rubric: Software Engineering : Factual Claims : Defect Cost Increase : Wolverton Ratios
See previous note on the IBM Systems Sciences Institute
In absolute numbers, the Wolverton are as follows: 139:455:977:7136:14102, claimed dollar costs of fixing an "average" defect. (Itself an absurd claim, see Leprechauns, I should perhaps write more on that.)
Rubric: Software Engineering : Factual Claims : Defect Cost Increase : Pressman Ratios
Background: I have been researching quantity and quality of empirical evidence underlying claims in software engineering. What do we know, and how well-established is that? See in particular https://leanpub.com/leprechauns which concludes that the answer is in (too) many cases "not much, and poor".
This applies in particular to the "Defect Cost Increase" claim, which is poorly supported by evidence. The claim states that the longer a defect stays undiscovered after being introduced in a software system's artefacts, the more expensive it is to correct.
| #!/bin/bash | |
| # Set this to 1 to reset the backlight to 100% after execution | |
| TEST_MODE=0 | |
| DBUS_SERVICE="local.org_kde_powerdevil" | |
| DBUS_PATH="/org/kde/Solid/PowerManagement/Actions/BrightnessControl" | |
| MAX_BRIGHTNESS=$(qdbus $DBUS_SERVICE $DBUS_PATH brightnessMax) | |
| // https://linuxjm.osdn.jp/html/LDP_man-pages/man2/recvmmsg.2.html in Rust | |
| // | |
| // 1. Run a receiver. | |
| // $ cargo run | |
| // 2. Send test data to a receiver. | |
| // $ while true; do echo $RANDOM > /dev/udp/127.0.0.1/1234; done | |
| use std::mem; | |
| use libc::*; |
rebase vs merge).rebase vs merge)reset vs checkout vs revert)git rev-parse)pull vs fetch)stash vs branch)reset vs checkout vs revert)
| { | |
| // miscellaneous | |
| "javascript.updateImportsOnFileMove.enabled": "always", | |
| "typescript.updateImportsOnFileMove.enabled": "always", | |
| "diffEditor.ignoreTrimWhitespace": false, | |
| // window | |
| "window.title": "🦙⚡🫡 – ${activeEditorShort}${separator}${rootName} – 🫡⚡🦙", | |
| "window.clickThroughInactive": false, |
Welcome to step by step hands-on guide to setup webpack in your upcoming typescript project. Please follow the steps and you should be able to create your own webpack project. Please download the source code from github.
You will learn below things:
webpack.config.js file and modify webpack.config.js based on our need.
Motor is an async Python driver for MongoDB.
You should use Motor when you're trying to interact with a MongoDB database in an asynchronous context. When you're making something that needs to be asynchronous (like a web server, or most commonly from what I've seen here, Discord bots), you also want all the database calls to be done asynchronously. But pymongo is synchronous, i.e it is blocking, and will block the execution of your asynchronous program for the time that it is talking to the database.
Thankfully for us, switching from pymongo to Motor isn't too hard, and won't need you to change much code. This process can be roughly summarized as:
Installing can be done with pip - pip install motor