Simply put, destructuring in Clojure is a way extract values from a datastructure and bind them to symbols, without having to explicitly traverse the datstructure. It allows for elegant and concise Clojure code.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
package com.dummys.learning; | |
import org.opencv.calib3d.Calib3d; | |
import org.opencv.core.*; | |
import org.opencv.features2d.*; | |
import org.opencv.highgui.Highgui; | |
import java.io.File; | |
import java.util.LinkedList; | |
import java.util.List; |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
(defun copy-current-line-position-to-clipboard () | |
"Copy current line in file to clipboard as '</path/to/file>:<line-number>'" | |
(interactive) | |
(let ((path-with-line-number | |
(concat (buffer-file-name) "::" (number-to-string (line-number-at-pos))))) | |
(when path-with-line-number | |
(with-temp-buffer | |
(insert path-with-line-number) | |
(clipboard-kill-region (point-min) (point-max))) | |
(message (concat path-with-line-number " copied to clipboard"))))) |
Created from the plain text reference card on orgmode.org Download this file, and open it in Emacs org-mode!
Created from the plain text reference card on orgmode.org Download this file, and open it in Emacs org-mode!
The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn't exist, and if a feature is documented incorrectly, then it's broken.
- Document the feature first. Figure out how you're going to describe the feature to users; if it's not documented, it doesn't exist. Documentation is the best way to define a feature in a user's eyes.
- Whenever possible, documentation should be reviewed by users (community or Spark Elite) before any development begins.
- Once documentation has been written, development should commence, and test-driven development is preferred.
- Unit tests should be written that test the features as described by the documentation. If the functionality ever comes out of alignment with the documentation, tests should fail.
- When a feature is being modified, it should be modified documentation-first.
- When documentation is modified, so should be the tests.
Listing pods with kubectl get pods
, then select a pod name and copy paste it into kubectl logs [pod name]
- I want to streamline my workflow and stop using the terminal
- learn more about kubernetes
- main kubernetes extension for Emacs out there is greedy for permissions